FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora User

 
 
LinkBack Thread Tools
 
Old 03-24-2011, 09:06 PM
Linuxguy123
 
Default F14 vlc update problem.

F14, fully up to date before this.
vlc installed.

# yum update
Loaded plugins: changelog, downloadonly, kmdl, refresh-packagekit
Setting up Update Process
Resolving Dependencies
--> Running transaction check
--> Processing Dependency: libdirect-1.4.so.0 for package:
vlc-extras-1.1.7-1.fc14.i686
--> Processing Dependency: libdirectfb-1.4.so.0 for package:
vlc-extras-1.1.7-1.fc14.i686
--> Processing Dependency: libfusion-1.4.so.0 for package:
vlc-extras-1.1.7-1.fc14.i686
---> Package directfb.i686 0:1.4.11-3.fc14 set to be updated
---> Package gnome-python2-extras.i686 0:2.25.3-29.fc14.1 set to be
updated
---> Package gnome-python2-gtkhtml2.i686 0:2.25.3-29.fc14.1 set to be
updated
---> Package gnome-python2-libegg.i686 0:2.25.3-29.fc14.1 set to be
updated
---> Package libgadu.i686 0:1.10.1-1.fc14 set to be updated
---> Package libgnome-keyring.i686 0:2.32.0-2.fc14 set to be updated
---> Package libgnome-keyring-devel.i686 0:2.32.0-2.fc14 set to be
updated
---> Package libv4l.i686 0:0.8.3-2.fc14 set to be updated
---> Package tcl.i686 1:8.5.9-1.fc14 set to be updated
---> Package tk.i686 1:8.5.9-1.fc14 set to be updated
---> Package xine-lib.i686 0:1.1.19-2.fc14.2 set to be updated
---> Package xine-lib-extras.i686 0:1.1.19-2.fc14.2 set to be updated
---> Package xulrunner.i686 0:1.9.2.16-1.fc14 set to be updated
---> Package xulrunner-devel.i686 0:1.9.2.16-1.fc14 set to be updated
--> Finished Dependency Resolution
DEBUG:
[]
Error: Package: vlc-extras-1.1.7-1.fc14.i686 (@rpmfusion-free-updates)
Requires: libfusion-1.4.so.0
Removing: directfb-1.4.11-2.fc14.i686 (@updates)
libfusion-1.4.so.0
Updated By: directfb-1.4.11-3.fc14.i686 (updates)
Not found
Available: directfb-1.4.3-1.fc14.i686 (fedora)
libfusion-1.4.so.0
Error: Package: vlc-extras-1.1.7-1.fc14.i686 (@rpmfusion-free-updates)
Requires: libdirect-1.4.so.0
Removing: directfb-1.4.11-2.fc14.i686 (@updates)
libdirect-1.4.so.0
Updated By: directfb-1.4.11-3.fc14.i686 (updates)
Not
found
Available: directfb-1.4.3-1.fc14.i686 (fedora)
libdirect-1.4.so.0
Error: Package: vlc-extras-1.1.7-1.fc14.i686 (@rpmfusion-free-updates)
Requires: libdirectfb-1.4.so.0
Removing: directfb-1.4.11-2.fc14.i686 (@updates)
libdirectfb-1.4.so.0
Updated By: directfb-1.4.11-3.fc14.i686 (updates)
Not found
Available: directfb-1.4.3-1.fc14.i686 (fedora)
libdirectfb-1.4.so.0
You could try using --skip-broken to work around the problem
You could try running: rpm -Va --nofiles --nodigest


--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
 
Old 03-24-2011, 09:48 PM
"Kevin J. Cummings"
 
Default F14 vlc update problem.

On 03/24/2011 06:06 PM, Linuxguy123 wrote:
> F14, fully up to date before this.
> vlc installed.
>
> # yum update
> Loaded plugins: changelog, downloadonly, kmdl, refresh-packagekit
> Setting up Update Process
> Resolving Dependencies
> --> Running transaction check
> --> Processing Dependency: libdirect-1.4.so.0 for package:
> vlc-extras-1.1.7-1.fc14.i686
> --> Processing Dependency: libdirectfb-1.4.so.0 for package:
> vlc-extras-1.1.7-1.fc14.i686
> --> Processing Dependency: libfusion-1.4.so.0 for package:
> vlc-extras-1.1.7-1.fc14.i686
> ---> Package directfb.i686 0:1.4.11-3.fc14 set to be updated
> ---> Package gnome-python2-extras.i686 0:2.25.3-29.fc14.1 set to be
> updated
> ---> Package gnome-python2-gtkhtml2.i686 0:2.25.3-29.fc14.1 set to be
> updated
> ---> Package gnome-python2-libegg.i686 0:2.25.3-29.fc14.1 set to be
> updated
> ---> Package libgadu.i686 0:1.10.1-1.fc14 set to be updated
> ---> Package libgnome-keyring.i686 0:2.32.0-2.fc14 set to be updated
> ---> Package libgnome-keyring-devel.i686 0:2.32.0-2.fc14 set to be
> updated
> ---> Package libv4l.i686 0:0.8.3-2.fc14 set to be updated
> ---> Package tcl.i686 1:8.5.9-1.fc14 set to be updated
> ---> Package tk.i686 1:8.5.9-1.fc14 set to be updated
> ---> Package xine-lib.i686 0:1.1.19-2.fc14.2 set to be updated
> ---> Package xine-lib-extras.i686 0:1.1.19-2.fc14.2 set to be updated
> ---> Package xulrunner.i686 0:1.9.2.16-1.fc14 set to be updated
> ---> Package xulrunner-devel.i686 0:1.9.2.16-1.fc14 set to be updated
> --> Finished Dependency Resolution
> DEBUG:
> []
> Error: Package: vlc-extras-1.1.7-1.fc14.i686 (@rpmfusion-free-updates)
> Requires: libfusion-1.4.so.0
> Removing: directfb-1.4.11-2.fc14.i686 (@updates)
> libfusion-1.4.so.0
> Updated By: directfb-1.4.11-3.fc14.i686 (updates)
> Not found
> Available: directfb-1.4.3-1.fc14.i686 (fedora)
> libfusion-1.4.so.0
> Error: Package: vlc-extras-1.1.7-1.fc14.i686 (@rpmfusion-free-updates)
> Requires: libdirect-1.4.so.0
> Removing: directfb-1.4.11-2.fc14.i686 (@updates)
> libdirect-1.4.so.0
> Updated By: directfb-1.4.11-3.fc14.i686 (updates)
> Not
> found
> Available: directfb-1.4.3-1.fc14.i686 (fedora)
> libdirect-1.4.so.0
> Error: Package: vlc-extras-1.1.7-1.fc14.i686 (@rpmfusion-free-updates)
> Requires: libdirectfb-1.4.so.0
> Removing: directfb-1.4.11-2.fc14.i686 (@updates)
> libdirectfb-1.4.so.0
> Updated By: directfb-1.4.11-3.fc14.i686 (updates)
> Not found
> Available: directfb-1.4.3-1.fc14.i686 (fedora)
> libdirectfb-1.4.so.0
> You could try using --skip-broken to work around the problem
> You could try running: rpm -Va --nofiles --nodigest

I'm seeing the same thing, but when I try and update directfb, and the
conflicts I'm seeing are with: xine-libs and mplayer.

> --> Running transaction check
> --> Processing Dependency: libdirect-1.4.so.0()(64bit) for package: xine-lib-1.1.19-22.fc14.x86_64
> --> Processing Dependency: libdirectfb-1.4.so.0()(64bit) for package: 4:mplayer-1.0-80_snap20110221.fc14.x86_64
> --> Processing Dependency: libdirectfb-1.4.so.0()(64bit) for package: xine-lib-1.1.19-22.fc14.x86_64
> --> Processing Dependency: libfusion-1.4.so.0()(64bit) for package: xine-lib-1.1.19-22.fc14.x86_64
> ---> Package directfb.x86_64 0:1.4.11-3.fc14 set to be updated
> --> Finished Dependency Resolution
> Error: Package: xine-lib-1.1.19-22.fc14.x86_64 (@anaconda-InstallationRepo-201010211827.x86_64)
> Requires: libfusion-1.4.so.0()(64bit)
> Removing: directfb-1.4.11-2.fc14.x86_64 (@updates)
> libfusion-1.4.so.0()(64bit)
> Updated By: directfb-1.4.11-3.fc14.x86_64 (updates)
> Not found
> Available: directfb-1.4.3-1.fc14.x86_64 (fedora)
> libfusion-1.4.so.0()(64bit)
> Error: Package: xine-lib-1.1.19-22.fc14.x86_64 (@anaconda-InstallationRepo-201010211827.x86_64)
> Requires: libdirect-1.4.so.0()(64bit)
> Removing: directfb-1.4.11-2.fc14.x86_64 (@updates)
> libdirect-1.4.so.0()(64bit)
> Updated By: directfb-1.4.11-3.fc14.x86_64 (updates)
> Not found
> Available: directfb-1.4.3-1.fc14.x86_64 (fedora)
> libdirect-1.4.so.0()(64bit)
> Error: Package: 4:mplayer-1.0-80_snap20110221.fc14.x86_64 (@atrpms)
> Requires: libdirectfb-1.4.so.0()(64bit)
> Removing: directfb-1.4.11-2.fc14.x86_64 (@updates)
> libdirectfb-1.4.so.0()(64bit)
> Updated By: directfb-1.4.11-3.fc14.x86_64 (updates)
> Not found
> Available: directfb-1.4.3-1.fc14.x86_64 (fedora)
> libdirectfb-1.4.so.0()(64bit)
> Error: Package: xine-lib-1.1.19-22.fc14.x86_64 (@anaconda-InstallationRepo-201010211827.x86_64)
> Requires: libdirectfb-1.4.so.0()(64bit)
> Removing: directfb-1.4.11-2.fc14.x86_64 (@updates)
> libdirectfb-1.4.so.0()(64bit)
> Updated By: directfb-1.4.11-3.fc14.x86_64 (updates)
> Not found
> Available: directfb-1.4.3-1.fc14.x86_64 (fedora)
> libdirectfb-1.4.so.0()(64bit)
> You could try using --skip-broken to work around the problem

Yet another well tested update. B^) And a bunch of dependencies with =
Requires instead of >= Requires.

Seems the new directfb package is now providing libdirectfb-1.4.so.5
instead of libdirectfb-1.4.so.0 .....

--skip-broken will update everything else, but the problem with directfb
remains.

--
Kevin J. Cummings
kjchome@verizon.net
cummings@kjchome.homeip.net
cummings@kjc386.framingham.ma.us
Registered Linux User #1232 (http://counter.li.org)
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
 
Old 03-24-2011, 10:16 PM
Michael Schwendt
 
Default F14 vlc update problem.

On Thu, 24 Mar 2011 18:48:53 -0400, Kevin wrote:

> > Updated By: directfb-1.4.11-3.fc14.x86_64 (updates)
> > Not found
> > Available: directfb-1.4.3-1.fc14.x86_64 (fedora)
> > libdirectfb-1.4.so.0()(64bit)
> > You could try using --skip-broken to work around the problem
>
> Yet another well tested update. B^) And a bunch of dependencies with =
> Requires instead of >= Requires.
>
> Seems the new directfb package is now providing libdirectfb-1.4.so.5
> instead of libdirectfb-1.4.so.0 .....
>
> --skip-broken will update everything else, but the problem with directfb
> remains.

Not really. Unless it breaks something in Fedora's repos. The problem is
with vlc, because RPM Fusion can only build against the new directfb if it
appears in Fedora stable Updates repo.

https://admin.fedoraproject.org/updates/directfb-1.4.11-3.fc14,xine-lib-1.1.19-2.fc14.2
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
 
Old 03-25-2011, 02:47 AM
"Kevin J. Cummings"
 
Default F14 vlc update problem.

On 03/24/2011 07:16 PM, Michael Schwendt wrote:
> On Thu, 24 Mar 2011 18:48:53 -0400, Kevin wrote:
>
>>> Updated By: directfb-1.4.11-3.fc14.x86_64 (updates)
>>> Not found
>>> Available: directfb-1.4.3-1.fc14.x86_64 (fedora)
>>> libdirectfb-1.4.so.0()(64bit)
>>> You could try using --skip-broken to work around the problem
>>
>> Yet another well tested update. B^) And a bunch of dependencies with =
>> Requires instead of >= Requires.
>>
>> Seems the new directfb package is now providing libdirectfb-1.4.so.5
>> instead of libdirectfb-1.4.so.0 .....
>>
>> --skip-broken will update everything else, but the problem with directfb
>> remains.
>
> Not really. Unless it breaks something in Fedora's repos. The problem is
> with vlc, because RPM Fusion can only build against the new directfb if it
> appears in Fedora stable Updates repo.

Hey,
I never said which packages were at fault. I actually complained about
the = dependencies instead of >= (which should have not then been a
problem). I didn't bother to check which repos built xine-lib or
mplayer on my system. Yeup, both were built by ATRPMS. B^) (and it
looks like linuxguy123's vlc-extras packages comes from rpmfusion.)

And I disagree about other repos not being able to build against a
package unless it is in Fedora stable. That's what Fedora
updates-testing, atrpms-testing, rpmfusion-free-updates-testing, and
rpmfusion-nonfree-updates-testing repos are all about. Then when fedora
pushes a package to stable, all the other repos have to do is push their
dependent packages to their stable repos as well. Its called planned
cooperation. I thought it was already going on. I never had this
problem getting a new nvidia or fglrx kernel driver from them any time a
new kernel gets released. How is this different?
(Maybe because the nvidia and fglrx builders were more diligent about
checking updates-testing for upcoming releases?)

> https://admin.fedoraproject.org/updates/directfb-1.4.11-3.fc14,xine-lib-1.1.19-2.fc14.2

Wow. 3 for, 3 against, a total Karma of 1, and they pushed to stable
(looks like because it had stayed in testing for 7 days. Just because 7
days had lapsed, it doesn't mean the update gets better, does it?)
Doesn't seem very overwhelmingly confident....

It looks like they knew there were still problems with the update, and
didn't care. OTOH, if they did poke the other maintainers and got no
response, I can't blame them very much. Ouch.

--
Kevin J. Cummings
kjchome@verizon.net
cummings@kjchome.homeip.net
cummings@kjc386.framingham.ma.us
Registered Linux User #1232 (http://counter.li.org)
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
 
Old 03-25-2011, 04:15 AM
Linuxguy123
 
Default F14 vlc update problem.

On Thu, 2011-03-24 at 23:47 -0400, Kevin J. Cummings wrote:
<snip>

I appreciate the discussion on this situation. I really didn't mean to
stir up the hornet's nest on this.

The good news is that a) yum works incredibly well at sorting out the
situation and allows everything else to update in spite of the vlc issue
and b) vlc still works.

We don't live in a perfect Linux world, but its still a very good one.


--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
 
Old 03-25-2011, 08:39 AM
Michael Schwendt
 
Default F14 vlc update problem.

On Thu, 24 Mar 2011 23:47:30 -0400, Kevin wrote:

> On 03/24/2011 07:16 PM, Michael Schwendt wrote:
> > On Thu, 24 Mar 2011 18:48:53 -0400, Kevin wrote:
> >
> >>> Updated By: directfb-1.4.11-3.fc14.x86_64 (updates)
> >>> Not found
> >>> Available: directfb-1.4.3-1.fc14.x86_64 (fedora)
> >>> libdirectfb-1.4.so.0()(64bit)
> >>> You could try using --skip-broken to work around the problem
> >>
> >> Yet another well tested update. B^) And a bunch of dependencies with =
> >> Requires instead of >= Requires.
> >>
> >> Seems the new directfb package is now providing libdirectfb-1.4.so.5
> >> instead of libdirectfb-1.4.so.0 .....
> >>
> >> --skip-broken will update everything else, but the problem with directfb
> >> remains.
> >
> > Not really. Unless it breaks something in Fedora's repos. The problem is
> > with vlc, because RPM Fusion can only build against the new directfb if it
> > appears in Fedora stable Updates repo.
>
> Hey,
> I never said which packages were at fault. I actually complained about
> the = dependencies instead of >= (which should have not then been a
> problem).

You haven't shown any such '=' dependencies. The thread only quotes
unresolvable SONAME dependencies. And those are "equal to" by definition.

> I didn't bother to check which repos built xine-lib or
> mplayer on my system. Yeup, both were built by ATRPMS. B^) (and it
> looks like linuxguy123's vlc-extras packages comes from rpmfusion.)
>
> And I disagree about other repos not being able to build against a
> package unless it is in Fedora stable.

We're talking past eachother. I refer to what RPM Fusion has been doing so
far, not to what they _could_ do. It's a matter of how the 3rd party's
build-system is set up and what it can do. As the most simple but unsafe
solution, they would need to make available additional build targets that
include Fedora's updates-testing repo. Not even Fedora does that. Test
updates are not included in Fedora's koji buildroots used for building
updates. With Fedora's process for stable distribution releases, one can
ask the Release Engineering team to make available new packages in a
buildroot, if one plans to build against them. Else the buildroot only
contains packages from the released distribution plus stable updates. This
adds some overhead, but helps with keeping the buildroot stable with
regard to various concerns.

> That's what Fedora
> updates-testing, atrpms-testing, rpmfusion-free-updates-testing, and
> rpmfusion-nonfree-updates-testing repos are all about. Then when fedora
> pushes a package to stable, all the other repos have to do is push their
> dependent packages to their stable repos as well.

That would require the third party repos to prepare their test updates
based on Fedora's updates-testing repo contents. With no guarantee that
all of the packages in updates-testing, which would be built against, are
good and will be released actually.

Alternatively, they would need to find a way how to build against Fedora's
koji buildroot package set. Dunno whether there's a reliable way to mirror
that (and quickly enough in order to be up-to-date with regard to builds
being added to [and removed from] it either automatically or by Fedora
releng).

> Its called planned
> cooperation. I thought it was already going on.

Not enough man-power. To do it painstakingly would create a lot of
overhead for Fedora package maintainers.

> I never had this
> problem getting a new nvidia or fglrx kernel driver from them any time a
> new kernel gets released. How is this different?
> (Maybe because the nvidia and fglrx builders were more diligent about
> checking updates-testing for upcoming releases?)

Yes, as far as I know, there has been some special effort at rebuilding
and pushing kernel related addons as early as _possible_, which makes the
broken deps a matter of a few hours only. Where broken dependencies
block updates from being installed, it's no big issue anyway, provided that
people are working on publishing the missing updates.

> > https://admin.fedoraproject.org/updates/directfb-1.4.11-3.fc14,xine-lib-1.1.19-2.fc14.2
>
> Wow. 3 for, 3 against, a total Karma of 1,

Not "3 for, 3 against". That's just the karma threshold configuration
for this update ticket. The update needs either +3 points to publish
it before 7 days have passed or -3 points to remove it from updates-testing.
It has received +1 from the packager (and +1 from an anonymous voter).

> (looks like because it had stayed in testing for 7 days. Just because 7
> days had lapsed, it doesn't mean the update gets better, does it?)
> Doesn't seem very overwhelmingly confident....
>
> It looks like they knew there were still problems with the update, and
> didn't care.

Or the update is fine as is, but the problem at RPM Fusion having to wait
for it to be marked stable remains.

> OTOH, if they did poke the other maintainers and got no
> response, I can't blame them very much. Ouch.

Why haven't you spent any karma points on that test update?
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
 
Old 03-25-2011, 04:42 PM
"Kevin J. Cummings"
 
Default F14 vlc update problem.

On 03/25/2011 05:39 AM, Michael Schwendt wrote:
> You haven't shown any such '=' dependencies. The thread only quotes
> unresolvable SONAME dependencies. And those are "equal to" by definition.

Now, your mixing up semantic meaning. Being dependent upon a particular
.so library release is the same as an = depends. When that library
version gets updated to a newer version, it *will* break the dependency,
regardless of whether the program will work or not work with the updated
library. That is one of the reasons named dependencies exist. If the
dependency were to be written as Requires directfb >= 1.4.3 then this
problem wouldn't exist. Yes, I understand that package maintainers
can't guarantee that a future library release won't bork the API into
making the program fail. That's a different can of worms that
developers need to learn about. Changing an ABI is a *BAD* thing to do.
Yet, it happens all the time in Linux. That doesn't make it right, it
just makes it a fact of life.

>> I didn't bother to check which repos built xine-lib or
>> mplayer on my system. Yeup, both were built by ATRPMS. B^) (and it
>> looks like linuxguy123's vlc-extras packages comes from rpmfusion.)
>>
>> And I disagree about other repos not being able to build against a
>> package unless it is in Fedora stable.
>
> We're talking past eachother. I refer to what RPM Fusion has been doing so
> far, not to what they _could_ do. It's a matter of how the 3rd party's
> build-system is set up and what it can do. As the most simple but unsafe
> solution, they would need to make available additional build targets that
> include Fedora's updates-testing repo. Not even Fedora does that. Test
> updates are not included in Fedora's koji buildroots used for building
> updates. With Fedora's process for stable distribution releases, one can
> ask the Release Engineering team to make available new packages in a
> buildroot, if one plans to build against them. Else the buildroot only
> contains packages from the released distribution plus stable updates. This
> adds some overhead, but helps with keeping the buildroot stable with
> regard to various concerns.

You're fixated with RPMFusion. B^) (Given the subject of this thread,
I can't blame you for that.) I have submitted my problem to ATRPMs
(that's where *my* problem with this update lies). You don't want to
know what one of the ATRPMS maintainers said about the Fedora directfb
maintainer. B^)

> That would require the third party repos to prepare their test updates
> based on Fedora's updates-testing repo contents. With no guarantee that
> all of the packages in updates-testing, which would be built against, are
> good and will be released actually.

I thought that's why it was a -testing repo.

> Alternatively, they would need to find a way how to build against Fedora's
> koji buildroot package set. Dunno whether there's a reliable way to mirror
> that (and quickly enough in order to be up-to-date with regard to builds
> being added to [and removed from] it either automatically or by Fedora
> releng).

I don't think that's the way to go. Too complicated, and koji stuff is
less stable than -testing. Perhaps its more equivalent to the atrpms
-bleeding stuff?

>> Its called planned
>> cooperation. I thought it was already going on.
>
> Not enough man-power. To do it painstakingly would create a lot of
> overhead for Fedora package maintainers.

OK, so we need more volunteers....

>>> https://admin.fedoraproject.org/updates/directfb-1.4.11-3.fc14,xine-lib-1.1.19-2.fc14.2
>>
>> Wow. 3 for, 3 against, a total Karma of 1,
>
> Not "3 for, 3 against". That's just the karma threshold configuration
> for this update ticket. The update needs either +3 points to publish
> it before 7 days have passed or -3 points to remove it from updates-testing.
> It has received +1 from the packager (and +1 from an anonymous voter).

That wasn't immediately clear to me from glancing at the URL you
provided. Yes, I understand its intended for developers who probably
understand the system better than I do, but if you're going to start
passing it around to non-developers, perhaps it should be clearer....

And +2 after 7 days still sounds like insufficient testing to me.

>> (looks like because it had stayed in testing for 7 days. Just because 7
>> days had lapsed, it doesn't mean the update gets better, does it?)
>> Doesn't seem very overwhelmingly confident....
>>
>> It looks like they knew there were still problems with the update, and
>> didn't care.
>
> Or the update is fine as is, but the problem at RPM Fusion having to wait
> for it to be marked stable remains.

I'm not convinced. But, you are entitled to your opinion as much as I
am entitled to mine.

>> OTOH, if they did poke the other maintainers and got no
>> response, I can't blame them very much. Ouch.
>
> Why haven't you spent any karma points on that test update?

I don't usually install from -testing, the lone exception is when the
stable stuff is broken and the -testing package contains the fixes for
the brokenness. And by the time I'm usually done testing, its been
pushed to stable anyways. B^)

--
Kevin J. Cummings
kjchome@verizon.net
cummings@kjchome.homeip.net
cummings@kjc386.framingham.ma.us
Registered Linux User #1232 (http://counter.li.org)
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
 
Old 03-25-2011, 06:25 PM
Michael Schwendt
 
Default F14 vlc update problem.

On Fri, 25 Mar 2011 13:42:09 -0400, Kevin wrote:

> On 03/25/2011 05:39 AM, Michael Schwendt wrote:
> > You haven't shown any such '=' dependencies. The thread only quotes
> > unresolvable SONAME dependencies. And those are "equal to" by definition.
>
> Now, your mixing up semantic meaning. Being dependent upon a particular
> .so library release is the same as an = depends. When that library
> version gets updated to a newer version, it *will* break the dependency,
> regardless of whether the program will work or not work with the updated
> library. That is one of the reasons named dependencies exist.

You show a clear misunderstanding of automatic SONAME dependencies.

> If the
> dependency were to be written as Requires directfb >= 1.4.3 then this
> problem wouldn't exist.

False. Due to the changed SONAME, the program would not even start.
The dynamic linker would fail to find the "old" library. That's why
the dependency is on a specific SONAME and not ">=".

> You're fixated with RPMFusion. B^) (Given the subject of this thread,
> I can't blame you for that.)

False, too. RPM Fusion just serves as an example of a 3rd party repository
when discussing [broken] dependencies.

> > That would require the third party repos to prepare their test updates
> > based on Fedora's updates-testing repo contents. With no guarantee that
> > all of the packages in updates-testing, which would be built against, are
> > good and will be released actually.
>
> I thought that's why it was a -testing repo.

Sure, but if you've built against _all_ of -testing, how do you know you
can release part of -testing and/or withdraw part of testing without pulling
anything that has been built against? You can't. It needs a well-defined
"stable" buildroot of packages to build against. -testing can't be included.

> > Alternatively, they would need to find a way how to build against Fedora's
> > koji buildroot package set. Dunno whether there's a reliable way to mirror
> > that (and quickly enough in order to be up-to-date with regard to builds
> > being added to [and removed from] it either automatically or by Fedora
> > releng).
>
> I don't think that's the way to go. Too complicated, and koji stuff is
> less stable than -testing. Perhaps its more equivalent to the atrpms
> -bleeding stuff?

Huh? Again you show that you don't know what you're talking of. "koji" is
just the name of the software that is Fedora's build system. It cannot
be "less stable than -testing" -- that doesn't make any sense at all to
say that. It seems you refer to downloading _unpublished_ builds found
within koji. That's a completely unrelated topic.

> > Not "3 for, 3 against". That's just the karma threshold configuration
> > for this update ticket. The update needs either +3 points to publish
> > it before 7 days have passed or -3 points to remove it from updates-testing.
> > It has received +1 from the packager (and +1 from an anonymous voter).
>
> That wasn't immediately clear to me from glancing at the URL you
> provided. Yes, I understand its intended for developers who probably
> understand the system better than I do, but if you're going to start
> passing it around to non-developers, perhaps it should be clearer....

Not true. The Fedora Updates System does not target developers. It
targets the entire Fedora community.

> And +2 after 7 days still sounds like insufficient testing to me.

Don't generalise.
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
 
Old 03-25-2011, 07:13 PM
Joe Zeff
 
Default F14 vlc update problem.

On 03/25/2011 12:25 PM, Michael Schwendt wrote:
> False. Due to the changed SONAME, the program would not even start.
> The dynamic linker would fail to find the "old" library. That's why
> the dependency is on a specific SONAME and not ">=".

I'm not quite sure I understand this. Are you saying that the
dependency is on a specific version, not *at least* a specific version
because the developer doesn't want to take the chance that some needed
feature isn't backward compatible? If not, why be so fussy? (Please
note that this isn't meant as a challenge; I'm sure there's a good
reason that I'm not aware of.)
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
 
Old 03-25-2011, 09:02 PM
Michael Schwendt
 
Default F14 vlc update problem.

On Fri, 25 Mar 2011 13:13:43 -0700, Joe wrote:

> > False. Due to the changed SONAME, the program would not even start.
> > The dynamic linker would fail to find the "old" library. That's why
> > the dependency is on a specific SONAME and not ">=".
>
> I'm not quite sure I understand this. Are you saying that the
> dependency is on a specific version, not *at least* a specific version
> because the developer doesn't want to take the chance that some needed
> feature isn't backward compatible? If not, why be so fussy? (Please
> note that this isn't meant as a challenge; I'm sure there's a good
> reason that I'm not aware of.)

It *is* a challenge, because if I understand your questions correctly [and
based on your word choice], I would need to start from the bottom up. How
much do you know about dynamically linked executables, shared libraries
and versioning schemes, and [automatically added ] shared library
dependencies with regard to RPM packaging? If you say "version", what
do you refer to?

Also, which "developer" do you refer to? The library developer? The
application developer (the app that uses a lib)? The package developer?
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
 

Thread Tools




All times are GMT. The time now is 07:59 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org