RFC: best way to fix the regular yum dependency problems with add-on packages from 3rd party repositories
7:21 a.m.
Hi all!
About one or two times a month a lot of people run into decency problems
like this:
$ sudo yum update
[...]
Resolving Dependencies
--> Running transaction check
---> Package kmod-nvidia.i686 0:173.14.09-5.lvn9 set to be updated
--> Processing Dependency: kmod-nvidia-2.6.25.11-97.fc9.i686 = 173.14.09-5.lvn9 for
package: kmod-nvidia
--> Running transaction check
---> Package kmod-nvidia-2.6.25.11-97.fc9.i686.i686 0:173.14.09-5.lvn9 set to be
updated
--> Processing Dependency: kernel-uname-r = 2.6.25.11-97.fc9.i686 for package:
kmod-nvidia-2.6.25.11-97.fc9.i686
--> Finished Dependency Resolution
kmod-nvidia-2.6.25.11-97.fc9.i686-173.14.09-5.lvn9.i686 from livna has depsolving
problems
--> Missing Dependency: kernel-uname-r = 2.6.25.11-97.fc9.i686 is needed by
package kmod-nvidia-2.6.25.11-97.fc9.i686-173.14.09-5.lvn9.i686 (livna)
Error: Missing Dependency: kernel-uname-r = 2.6.25.11-97.fc9.i686 is needed by
package kmod-nvidia-2.6.25.11-97.fc9.i686-173.14.09-5.lvn9.i686 (livna)
I'd like to find a solution to solve this problem (which is *not*
specific to kernel modules/kmods and imho not really Livna's fault), as
it seems to annoy users (and developers and mailing list subscribers, as
those receive bug reports about this kind of problem nearly each time) a
lot. The problem itself is not easy (I try to explain it below) and I'm
not sure what's the best way to fix it -- hence this RFC.
= Short problem description =
Livna (which soon will be obsoleted by RPM Fusion) is shipping quite a
bunch of add-on packages for Fedora packages. Most if not all of those
add-on packages only work for a specific version of the software they
enhance; thus the add-on packages from Livna have a strict dependency on
the Fedora package they were build for. That leads to trouble when the
Fedora package and its add-on package get updated, as there is no single
point in time for Livna to ship the add-on package as update without
causing trouble for users: Yum might try to install the updated add-on
package before the Fedora mirror yum chose offers the updated Fedora
package (like in the example above) or vice versa.
= Long problem description =
There are several add-on packages in Livna (soon: RPM Fusion) that have
a hard dep on a specific Fedora package, as the Livna package was build
specifically for this Fedora package. Among those packages are all
kernel-module packages (kmods), but there are a lot of other add-on
packages with a hard dependency on a specific Fedora package --
audacious-plugins-freeworld, k3b-extras-freeworld or
xine-lib-extras-freeworld (those in Livna still carry the old nonfree
postfix instead of the new term freeworld) are some of them.
When Fedora releases a new audacious, k3b, kernel or xine-lib we in
Livna try to ship a updated version of the add-on package in a
just-in-time matter -- e.g. when the new Fedora packages hits the repo
and get announced on the package-announce list we try our best to push
the updated add-on package (which we normally try to prepare in advance)
immediately. Thus often the newly add-on packages are in the repo just
10 or 30 minutes after the updated Fedora package was pushed.
This indirectly leads to trouble for the users. Livna doesn't have that
many mirrors and yum on most systems fetches repodata and packages
straight from the master repo -- thus yum sees the updated add-on
package quickly and tries to install it. That fails quite often in the
first 24 hours after the updated Fedora package was pushed, as yum most
of the time retrieves repodata and packages from Fedora mirrors all over
the world -- but those mirrors often have not retrieved the updated
Fedora package yet. Yum's metadata-caching or temporary inactive mirros
that were not checked by mirrormanager yet can make things worse.
Note that sometimes the situation might be the other way around as well
-- depending on the Livna mirror yum chose it might happen that yum
tries to install the updated Fedora package before it sees the updated
add-on package. That often leads to dependency issues in yum as well
(for non-kernel-module packages), as the Livna package the user has
installed on his system strictly requires the locally installed Fedora
package that yum tries to be update. That's why "just wait a bit with
the push for the updated Livna package" is no option here either.
Site note: all this might become a bigger problem in RPM Fusion in the
future, when things in the nonfree have a hard dep on a package in the
free repo (which can lead to similar problems in case yum updates the
repodata for the nonfree repo, but not for the free repo). But I suspect
it should not happen that often.
= RFC =
I'm unsure what's the best way to fix or work around this problem.
* yum is the central piece of software in this game, thus it's easy to
say "it needs to be fixed in yum; it needs to be taught to do a second
look at the right place to find what's needed"; I'm a bit unsure myself
if that's a good idea and suspect that skvidal doesn't like the idea to
much either.
* Livna/RPM Fusion could ship the updated Fedora packages in Livna/RPM
Fusion repos together with the add-on packages; hard to get right, a bit
ugly and I assume some people will dislike this idea. It'll get worse in
RPM Fusion due to the split in free and nonfree repos -- kernels would
need to be shipped in both repos to avoid similar problem :-/ I also
fear that shipping nonfree kernel modules and the GPLed kernels in one
repo might some people yell "license violation"
* your suggestion here!
= EOF =
Comments?
CU
knurd
8:41 a.m.
Thorsten Leemhuis wrote:
Hi all!
About one or two times a month a lot of people run into decency
problems like this:
>
> Error: Missing Dependency: kernel-uname-r = 2.6.25.11-97.fc9.i686 is
> needed by
> package kmod-nvidia-2.6.25.11-97.fc9.i686-173.14.09-5.lvn9.i686 (livna)
Every day I run into dependency problems like this, just with Rawhide
rpms, not even third part ones:
$ yum update phonon*
Error: Missing Dependency: phonon = 4.2.0-1.fc10 is needed by
package phonon-backend-gstreamer-4.2.0-1.fc10.x86_64 (installed)
$ yum update digikam*
Transaction Check Error:
file /usr/share/icons/oxygen/128x128/apps/digikam.png from install of
digikam-0.10.0-0.1.beta2.fc10.x86_64 conflicts with file from package
oxygen-icon-theme-4.1.0-1.fc10.noarch
Neither of these dependency issues is flagged in: "rawhide report:
20080802 changes"
It would really help if yum would automatically skip any rpm that
conflicted with any *installed* rpm. Both for Rawhide and third-party rpms.
John
9:05 a.m.
On Sat, 02 Aug 2008 09:41:33 -0400, John Ellson wrote:
Thorsten Leemhuis wrote:
> Hi all!
>
> About one or two times a month a lot of people run into decency
> problems like this:
>
>>
>> Error: Missing Dependency: kernel-uname-r = 2.6.25.11-97.fc9.i686 is
>> needed by
>> package kmod-nvidia-2.6.25.11-97.fc9.i686-173.14.09-5.lvn9.i686 (livna)
Every day I run into dependency problems like this, just with Rawhide
rpms, not even third part ones:
$ yum update phonon*
Error: Missing Dependency: phonon = 4.2.0-1.fc10 is needed by
package phonon-backend-gstreamer-4.2.0-1.fc10.x86_64 (installed)
There's phonon-backend-gst which is supposed to obsolete that pkg
(if the Obsoletes/Provides tags in it are correct).
The rawhide broken deps checker cannot detect this as it no longer sees
the old phono-backend-gstreamer. (and I think the repoclosure version that
is used doesn't handle obsoletes yet anyway)
$ yum update digikam*
Transaction Check Error:
file /usr/share/icons/oxygen/128x128/apps/digikam.png from install of
digikam-0.10.0-0.1.beta2.fc10.x86_64 conflicts with file from package
oxygen-icon-theme-4.1.0-1.fc10.noarch
Conflicts are not dependency issues and are not checked for.
Neither of these dependency issues is flagged in: "rawhide
report:
20080802 changes"
12:41 p.m.
Michael Schwendt wrote:
> $ yum update phonon*
> Error: Missing Dependency: phonon = 4.2.0-1.fc10 is needed by
> package phonon-backend-gstreamer-4.2.0-1.fc10.x86_64 (installed)
>
There's phonon-backend-gst which is supposed to obsolete that pkg
(if the Obsoletes/Provides tags in it are correct).
Oops, fixed in phonon-4.2.0-3 (building now).
The rawhide broken deps checker cannot detect this as it no longer
sees
the old phono-backend-gstreamer. (and I think the repoclosure version that
is used doesn't handle obsoletes yet anyway)
> $ yum update digikam*
> Transaction Check Error:
> file /usr/share/icons/oxygen/128x128/apps/digikam.png from install of
> digikam-0.10.0-0.1.beta2.fc10.x86_64 conflicts with file from package
> oxygen-icon-theme-4.1.0-1.fc10.noarch
Conflicts are not dependency issues and are not checked for.
blarg. easyfix too, forthcoming.
-- Rex
4:04 p.m.
If you like an opinion, it is that Conflicts are difficult to mantain also
for a knowledge packager. There
are reason for conflicts but, no matter when, it is best, if possible, to
try to rename the package via obsoletes/Provides.
Only an opinion.
Regards
On Sat, Aug 2, 2008 at 4:05 PM, Michael Schwendt <mschwendt(a)gmail.com>wrote:
On Sat, 02 Aug 2008 09:41:33 -0400, John Ellson wrote:
> Thorsten Leemhuis wrote:
> > Hi all!
> >
> > About one or two times a month a lot of people run into decency
> > problems like this:
> >
> >>
> >> Error: Missing Dependency: kernel-uname-r = 2.6.25.11-97.fc9.i686 is
> >> needed by
> >> package kmod-nvidia-2.6.25.11-97.fc9.i686-173.14.09-5.lvn9.i686
(livna)
>
> Every day I run into dependency problems like this, just with Rawhide
> rpms, not even third part ones:
>
> $ yum update phonon*
> Error: Missing Dependency: phonon = 4.2.0-1.fc10 is needed by
> package phonon-backend-gstreamer-4.2.0-1.fc10.x86_64 (installed)
>
There's phonon-backend-gst which is supposed to obsolete that pkg
(if the Obsoletes/Provides tags in it are correct).
The rawhide broken deps checker cannot detect this as it no longer sees
the old phono-backend-gstreamer. (and I think the repoclosure version that
is used doesn't handle obsoletes yet anyway)
> $ yum update digikam*
> Transaction Check Error:
> file /usr/share/icons/oxygen/128x128/apps/digikam.png from install of
> digikam-0.10.0-0.1.beta2.fc10.x86_64 conflicts with file from package
> oxygen-icon-theme-4.1.0-1.fc10.noarch
Conflicts are not dependency issues and are not checked for.
> Neither of these dependency issues is flagged in: "rawhide report:
> 20080802 changes"
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
9:09 a.m.
On 02.08.2008 15:41, John Ellson wrote:
Thorsten Leemhuis wrote:
> About one or two times a month a lot of people run into decency
> problems like this:
>> Error: Missing Dependency: kernel-uname-r = 2.6.25.11-97.fc9.i686 is
>> needed by
>> package kmod-nvidia-2.6.25.11-97.fc9.i686-173.14.09-5.lvn9.i686 (livna)
Every day I run into dependency problems like this, just with Rawhide
rpms, not even third part ones:
Well, the two problems you mention are of a different kind.
Reply out of order:
Neither of these dependency issues is flagged in: "rawhide
report:
20080802 changes"
It would really help if yum would automatically skip any rpm that
conflicted with any *installed* rpm. Both for Rawhide and third-party rpms.
$ yum update phonon*
Error: Missing Dependency: phonon = 4.2.0-1.fc10 is needed by
package phonon-backend-gstreamer-4.2.0-1.fc10.x86_64 (installed)
Look closer! It says "[...] (installed)" there -- the scripts that
generates the rawhide report can't know what you have one your harddisk
and thus it can't detect this broken dep.
It seems phonon-backend-gstreamer is not in rawhide anymore. I would
assume phonon-backend-gst should obsolete it, but doesn't. That's a bug
that needs to be reported and fixed, so it's good that yum boils out here.
Further: I'm not familiar with the skip-broken plugin, but this might be
a case where skipping updates due to broken deps might do the wrong
thing to do. At least I have a few old packages(¹) on my disk now and
then and I would not want to skip updates just because those old 8and
most of the time unneeded) cruft requires things that are not available
anymore.
(¹) -- packages that were dropped from Fedora or a 3rd party repo;
packages that have been installed manually. Yes, I clean those up now
and then ("package-cleanup --orphans"), but there are new ones every few
months.
$ yum update digikam*
Transaction Check Error:
file /usr/share/icons/oxygen/128x128/apps/digikam.png from install of
digikam-0.10.0-0.1.beta2.fc10.x86_64 conflicts with file from package
oxygen-icon-theme-4.1.0-1.fc10.noarch
A bug as well. It's good that yum boils out, because then someone will
actually report it sooner or later; then someone else will fix it sooner
or later.
Further: Looking for file conflicts in all packages is a very
time-consuming task -- it takes many hours iirc and thus to long to do
it for each rawhide push. In the old Fedora Extras days mschwendt iirc
had a script that did such checks that; he started it now and then
manually. But this script just like a lot of other (semi-)automatic
check scripts from Extras afaics one got lost/forgotten during the Core
and Extras merge. :-((
Cu
knurd
9:34 a.m.
Thorsten Leemhuis wrote:
On 02.08.2008 15:41, John Ellson wrote:
> Thorsten Leemhuis wrote:
>> About one or two times a month a lot of people run into decency
>> problems like this:
>>> Error: Missing Dependency: kernel-uname-r = 2.6.25.11-97.fc9.i686
>>> is needed by
>>> package kmod-nvidia-2.6.25.11-97.fc9.i686-173.14.09-5.lvn9.i686
>>> (livna)
> Every day I run into dependency problems like this, just with Rawhide
> rpms, not even third part ones:
Well, the two problems you mention are of a different kind.
Reply out of order:
> Neither of these dependency issues is flagged in: "rawhide report:
> 20080802 changes"
>
> It would really help if yum would automatically skip any rpm that
> conflicted with any *installed* rpm. Both for Rawhide and
> third-party rpms.
>
> $ yum update phonon*
> Error: Missing Dependency: phonon = 4.2.0-1.fc10 is needed by
> package phonon-backend-gstreamer-4.2.0-1.fc10.x86_64 (installed)
Look closer! It says "[...] (installed)" there -- the scripts that
generates the rawhide report can't know what you have one your
harddisk and thus it can't detect this broken dep.
But (1) the rawhide reports do know what is in the rawhide repository
that might be installed, and which shouldn't conflict if they are.
But (2) I suggested that yum, on the client, should automatically skip
over new rpms (and and new rpms that depend on the new rpm)
that conflict with an installed rpm.
It seems phonon-backend-gstreamer is not in rawhide anymore. I would
assume phonon-backend-gst should obsolete it, but doesn't. That's a
bug that needs to be reported and fixed, so it's good that yum boils
out here.
I'd generate a BZ report, but BZ is down.
There seems to be some kind of circular dependency.
$ rpm -e phonon-backend-gstreamer.x86_64
error: Failed dependencies:
phonon-backend is needed by (installed) phonon-4.2.0-1.fc10.x86_64
Can anyone tell me how to a remove of one rpm, and an upgrade or install
of another, as an atomic operation?
Something like:
rpm -e XXX -i YYY
Further: I'm not familiar with the skip-broken plugin, but this might
be a case where skipping updates due to broken deps might do the wrong
thing to do. At least I have a few old packages(¹) on my disk now and
then and I would not want to skip updates just because those old 8and
most of the time unneeded) cruft requires things that are not
available anymore.
(¹) -- packages that were dropped from Fedora or a 3rd party repo;
packages that have been installed manually. Yes, I clean those up now
and then ("package-cleanup --orphans"), but there are new ones every
few months.
> $ yum update digikam*
> Transaction Check Error:
> file /usr/share/icons/oxygen/128x128/apps/digikam.png from install
> of digikam-0.10.0-0.1.beta2.fc10.x86_64 conflicts with file from
> package oxygen-icon-theme-4.1.0-1.fc10.noarch
A bug as well. It's good that yum boils out, because then someone will
actually report it sooner or later; then someone else will fix it
sooner or later.
Once BZ is resurrected..
Further: Looking for file conflicts in all packages is a very
time-consuming task -- it takes many hours iirc and thus to long to do
it for each rawhide push. In the old Fedora Extras days mschwendt iirc
had a script that did such checks that; he started it now and then
manually. But this script just like a lot of other (semi-)automatic
check scripts from Extras afaics one got lost/forgotten during the
Core and Extras merge. :-((
Fine. Don't check it on the server. Just have yum on the client
recover gracefully from these and skip over them.
That would also solve the livna problem.
John
1:57 a.m.
On 02.08.2008 16:34, John Ellson wrote:
Thorsten Leemhuis wrote:
> On 02.08.2008 15:41, John Ellson wrote:
>> Thorsten Leemhuis wrote:
>> Neither of these dependency issues is flagged in: "rawhide report:
>> 20080802 changes"
>> It would really help if yum would automatically skip any rpm that
>> conflicted with any *installed* rpm. Both for Rawhide and
>> third-party rpms.
>> $ yum update phonon*
>> Error: Missing Dependency: phonon = 4.2.0-1.fc10 is needed by
>> package phonon-backend-gstreamer-4.2.0-1.fc10.x86_64 (installed)
> Look closer! It says "[...] (installed)" there -- the scripts that
> generates the rawhide report can't know what you have one your
> harddisk and thus it can't detect this broken dep.
But (1) the rawhide reports do know what is in the rawhide repository
that might be installed, and which shouldn't conflict if they are.
I can't follow, sorry. As mentioned already, phonon-backend-gstreamer
isn't in rawhide anymore. Yes, it once was, but you can't expect the
script to check all "was once in rawhide" packages, as the script then
would take ages to complete.
But whatever; Rex fixed it afaics, so this specific problem should
vanish today.
But (2) I suggested that yum, on the client, should automatically
skip
over new rpms (and and new rpms that depend on the new rpm)
that conflict with an installed rpm.
But especially in rawhide this bug must be fixed. If users don't notice
it it will never be fixed, which would lead to a Fedora which is worse
in the end.
[...]
> Further: Looking for file conflicts in all packages is a very
> time-consuming task -- it takes many hours iirc and thus to long to do
> it for each rawhide push. In the old Fedora Extras days mschwendt iirc
> had a script that did such checks that; he started it now and then
> manually. But this script just like a lot of other (semi-)automatic
> check scripts from Extras afaics one got lost/forgotten during the
> Core and Extras merge. :-((
Fine. Don't check it on the server. Just have yum on the client
recover gracefully from these and skip over them.
That would also solve the livna problem.
Feels to me like a car where that is oxidizing all over the place. Yeah,
you go out and by a new parts for the car body. It then will look good
on a first sight again, but the car structure will continue to rust;
sooner or later it will fall apart might do damage then.
CU
knurd
2:07 a.m.
On Sun, 03 Aug 2008 08:57:08 +0200, Thorsten Leemhuis wrote:
On 02.08.2008 16:34, John Ellson wrote:
> Thorsten Leemhuis wrote:
>> On 02.08.2008 15:41, John Ellson wrote:
>>> Thorsten Leemhuis wrote:
>>> Neither of these dependency issues is flagged in: "rawhide report:
>>> 20080802 changes"
>>> It would really help if yum would automatically skip any rpm that
>>> conflicted with any *installed* rpm. Both for Rawhide and
>>> third-party rpms.
>>> $ yum update phonon*
>>> Error: Missing Dependency: phonon = 4.2.0-1.fc10 is needed by
>>> package phonon-backend-gstreamer-4.2.0-1.fc10.x86_64 (installed)
>> Look closer! It says "[...] (installed)" there -- the scripts that
>> generates the rawhide report can't know what you have one your
>> harddisk and thus it can't detect this broken dep.
> But (1) the rawhide reports do know what is in the rawhide repository
> that might be installed, and which shouldn't conflict if they are.
I can't follow, sorry. As mentioned already, phonon-backend-gstreamer
isn't in rawhide anymore. Yes, it once was, but you can't expect the
script to check all "was once in rawhide" packages, as the script then
would take ages to complete.
It doesn't take much longer, because for normal pkg updates, it would only
examine the latest pkg release. It should take into account obsolete
binary pkgs from the previous compose, however. Only *that* would help
with detecting incorrect/missing "Obsoletes" tags (which is something my
modified repoclosure handles, because in Extras we've had up to two pkg
releases in the repo). On the contrary, the Rawhide report is like a fresh
install of only the latest pkg releases, and one can only hope that there
are enough testers who find and report the additional update/upgrade
problems.
9:36 a.m.
On Sat, 02 Aug 2008 16:09:40 +0200, Thorsten Leemhuis wrote:
Further: Looking for file conflicts in all packages is a very
time-consuming task -- it takes many hours iirc and thus to long to do
it for each rawhide push. In the old Fedora Extras days mschwendt iirc
had a script that did such checks that; he started it now and then
manually. But this script just like a lot of other (semi-)automatic
check scripts from Extras afaics one got lost/forgotten during the Core
and Extras merge. :-((
Not this one, as it wasn't public. The reason I've stopped running it
is that running it and maintaining the bz tickets would be on my own
initiative, since the official policy on package conflicts [1] is
half-hearted, and I don't like that policy. All conflicts (whether
implicit or explicit) in a repository are a real PITA, if they are
revealed no later than through new dependencies during a yum update.
Florian La Roche has run a different script that can also detect conflicts
between files and symlinks (which is one of the things that cannot
be detected by examining remote metadata only).
[1] https://fedoraproject.org/wiki/Packaging/Conflicts
11:59 a.m.
On Sat, 02 Aug 2008 16:09:40 +0200, Thorsten Leemhuis wrote:
> $ yum update phonon*
> Error: Missing Dependency: phonon = 4.2.0-1.fc10 is needed by
> package phonon-backend-gstreamer-4.2.0-1.fc10.x86_64 (installed)
Look closer! It says "[...] (installed)" there -- the scripts that
generates the rawhide report can't know what you have one your harddisk
and thus it can't detect this broken dep.
It seems phonon-backend-gstreamer is not in rawhide anymore. I would
assume phonon-backend-gst should obsolete it, but doesn't. That's a bug
that needs to be reported and fixed, so it's good that yum boils out here.
The Obsoletes is not high enough:
Obsoletes: %{name}-backend-gstreamer < 4.2-2
But 4.2.0-1.fc10 is "higher", because: 4.2.0 > 4.2
Ought to be:
Obsoletes: %{name}-backend-gstreamer < 4.2.0-2
10:11 a.m.
On Sat, Aug 2, 2008 at 3:41 PM, John Ellson <john.ellson(a)comcast.net> wrote:
Thorsten Leemhuis wrote:
>
> Hi all!
>
> About one or two times a month a lot of people run into decency problems
> like this:
>
>>
>> Error: Missing Dependency: kernel-uname-r = 2.6.25.11-97.fc9.i686 is
>> needed by
>> package kmod-nvidia-2.6.25.11-97.fc9.i686-173.14.09-5.lvn9.i686 (livna)
Every day I run into dependency problems like this, just with Rawhide rpms,
not even third part ones:
$ yum update phonon*
Error: Missing Dependency: phonon = 4.2.0-1.fc10 is needed by package
phonon-backend-gstreamer-4.2.0-1.fc10.x86_64 (installed)
$ yum update digikam*
Transaction Check Error:
file /usr/share/icons/oxygen/128x128/apps/digikam.png from install of
digikam-0.10.0-0.1.beta2.fc10.x86_64 conflicts with file from package
oxygen-icon-theme-4.1.0-1.fc10.noarch
Just wondering.. but can't soft dependencies solve this image problem
(should come in RPM 4.6 [1])?
Or am i getting the wrong idea about soft dependencies?
[1] http://wiki.rpm.org/Releases/4.5.90#head-8cfe2fe7ac703083c6a2ab2610718ba8...
Neither of these dependency issues is flagged in: "rawhide
report: 20080802
changes"
It would really help if yum would automatically skip any rpm that conflicted
with any *installed* rpm. Both for Rawhide and third-party rpms.
John
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
12:36 p.m.
New subject: RFC: best way to fix the regular yum dependency problems with add-on packages from 3rd party repositories
Mark <markg85 <at> gmail.com> writes:
> file /usr/share/icons/oxygen/128x128/apps/digikam.png from
install of
> digikam-0.10.0-0.1.beta2.fc10.x86_64 conflicts with file from package
> oxygen-icon-theme-4.1.0-1.fc10.noarch
Just wondering.. but can't soft dependencies solve this image problem
(should come in RPM 4.6 [1])?
No. The offending file simply needs to be removed from one of those packages.
Soft dependencies don't help solving this at all.
Kevin Kofler
9:47 a.m.
Thorsten Leemhuis wrote:
> $ sudo yum update
> [...]
> Resolving Dependencies
> --> Running transaction check
> ---> Package kmod-nvidia.i686 0:173.14.09-5.lvn9 set to be updated
> --> Processing Dependency: kmod-nvidia-2.6.25.11-97.fc9.i686 =
> 173.14.09-5.lvn9 for package: kmod-nvidia
> --> Running transaction check
> ---> Package kmod-nvidia-2.6.25.11-97.fc9.i686.i686 0:173.14.09-5.lvn9
> set to be updated
> --> Processing Dependency: kernel-uname-r = 2.6.25.11-97.fc9.i686 for
> package: kmod-nvidia-2.6.25.11-97.fc9.i686
> --> Finished Dependency Resolution
> kmod-nvidia-2.6.25.11-97.fc9.i686-173.14.09-5.lvn9.i686 from livna has
> depsolving problems
> --> Missing Dependency: kernel-uname-r = 2.6.25.11-97.fc9.i686 is
> needed by
> package kmod-nvidia-2.6.25.11-97.fc9.i686-173.14.09-5.lvn9.i686 (livna)
> Error: Missing Dependency: kernel-uname-r = 2.6.25.11-97.fc9.i686 is
> needed by
> package kmod-nvidia-2.6.25.11-97.fc9.i686-173.14.09-5.lvn9.i686 (livna)
I'd like to find a solution to solve this problem (which is *not*
I got the impression that this is exactly what --skip-broken is for; yet
it either doesn't get all cases, or isn't enabled by default. IMHO it
sh/c/ould go further. Eg. during a yum update, every package that is
- available
- non-conflicting
- non-dependency breaking
- is actually downloadable/ed
should get updated when yum is using Fedora default yum config.
eg: So in the inter-related repo problem, the user would still get that
security update for firefox installed, even though the new kernel
doesn't have a matching nvidia yet {or vice-versa}. The yum/PK summary
should simply state:
installed 27 packages: x y z etc
3 packages are not currently downloadable: a b h
2 packages have conflicting requirements h k
leading to 7 packages not being installed at this time. These packages
will be checked again at the next update. [ps. PK shouldn't keep
informing me that there is updates available if the remaining 'to do'
set can't resolve !]
In this case RF shouln't care when they make a new kmod available {ie
can make it early}, and F wouldn't care when they release a security
update, since only specific conflicting packages will not get
immediately updated at the next update, rather than the current
situation where conflict/deps/download problems can lead to long term
inability for yum to do it's job.
Does this at least make logical sense, even if it might be difficult to
achieve ?
DaveT.
2:17 a.m.
On 02.08.2008 16:47, David Timms wrote:
Thorsten Leemhuis wrote:
>> $ sudo yum update
>> [...]
>> Resolving Dependencies
>> --> Running transaction check
>> ---> Package kmod-nvidia.i686 0:173.14.09-5.lvn9 set to be updated
>> --> Processing Dependency: kmod-nvidia-2.6.25.11-97.fc9.i686 =
>> 173.14.09-5.lvn9 for package: kmod-nvidia
>> --> Running transaction check
>> ---> Package kmod-nvidia-2.6.25.11-97.fc9.i686.i686 0:173.14.09-5.lvn9
>> set to be updated
>> --> Processing Dependency: kernel-uname-r = 2.6.25.11-97.fc9.i686 for
>> package: kmod-nvidia-2.6.25.11-97.fc9.i686
>> --> Finished Dependency Resolution
>> kmod-nvidia-2.6.25.11-97.fc9.i686-173.14.09-5.lvn9.i686 from livna has
>> depsolving problems
>> --> Missing Dependency: kernel-uname-r = 2.6.25.11-97.fc9.i686 is
>> needed by
>> package kmod-nvidia-2.6.25.11-97.fc9.i686-173.14.09-5.lvn9.i686 (livna)
>> Error: Missing Dependency: kernel-uname-r = 2.6.25.11-97.fc9.i686 is
>> needed by
>> package kmod-nvidia-2.6.25.11-97.fc9.i686-173.14.09-5.lvn9.i686 (livna)
> I'd like to find a solution to solve this problem (which is *not*
I got the impression that this is exactly what --skip-broken is for;
Yeah, maybe. But I'd prefer to solve problems instead of hiding them :-/
yet it either doesn't get all cases, or isn't enabled by
default.
Especially the latter is the key point. :-/
[...] The yum/PK summary
should simply state:
installed 27 packages: x y z etc
3 packages are not currently downloadable: a b h
2 packages have conflicting requirements h k
leading to 7 packages not being installed at this time. These packages
will be checked again at the next update. [ps. PK shouldn't keep
informing me that there is updates available if the remaining 'to do'
set can't resolve !]
I suppose a lot of users won't look that close and some GUIs will likely
hide such a output. So I don't like that idea to much, as it afaik could
block important updates of certain packages for months or years if the
user has a local packages (an orphan or a manually installed RPM from
non-Fedora repos) installed that is the culprit for the dependency problem.
What IMHO might work is a "skip broken" plugin that for example ignores
broken deps for a certain timeframe (say 48 oder 72 hours after the
problems was hit for the first time) and boils out after that in case
the broken dep still isn't fixed.
CU
knurd
10:39 a.m.
On Sun, 2008-08-03 at 09:17 +0200, Thorsten Leemhuis wrote:
I suppose a lot of users won't look that close and some GUIs will
likely
hide such a output. So I don't like that idea to much, as it afaik could
block important updates of certain packages for months or years if the
user has a local packages (an orphan or a manually installed RPM from
non-Fedora repos) installed that is the culprit for the dependency problem.
What IMHO might work is a "skip broken" plugin that for example ignores
broken deps for a certain timeframe (say 48 oder 72 hours after the
problems was hit for the first time) and boils out after that in case
the broken dep still isn't fixed.
1. skip-broken is not a plugin, anymore. It is in core yum code, now.
2. doing it via date is very odd. If only b/c the only date we could use
if the file timestamp of the pkg and packages will sometimes sit in a
space before being pushed to a repo officially. So it will be something
of a crapshoot what it says is really broken or not.
I think a tool to detect all these issues is worth discussing, not sure
how we catch all possible conflicts, though.
-sv
11:10 a.m.
On 04.08.2008 17:39, Seth Vidal wrote:
On Sun, 2008-08-03 at 09:17 +0200, Thorsten Leemhuis wrote:
> I suppose a lot of users won't look that close and some GUIs will likely
> hide such a output. So I don't like that idea to much, as it afaik could
> block important updates of certain packages for months or years if the
> user has a local packages (an orphan or a manually installed RPM from
> non-Fedora repos) installed that is the culprit for the dependency problem.
>
> What IMHO might work is a "skip broken" plugin that for example ignores
> broken deps for a certain timeframe (say 48 oder 72 hours after the
> problems was hit for the first time) and boils out after that in case
> the broken dep still isn't fixed.
[...]
2. doing it via date is very odd. If only b/c the only date we could use
if the file timestamp of the pkg and packages will sometimes sit in a
space before being pushed to a repo officially. So it will be something
of a crapshoot what it says is really broken or not.
That why I didn't suggest to use the build date and mentioned to use "48
or 72 hours after the problems was hit for the first time". That of
cause would need to be managed on the client (e.g. for each broken dep
write down somewhere when the problem showed up; if the same problem
shows up with the same packages 72 hours later then boil out to make
sure the user gets aware of the issue).
But yes, agreed, using the date is a bit odd, but I'd say it could solve
the "Skip broken for weeks prevented that I didn't get the crucial
update" problem. Or is there a better way around that?
Cu
knurd
12:25 p.m.
On Mon, 2008-08-04 at 18:10 +0200, Thorsten Leemhuis wrote:
That why I didn't suggest to use the build date and mentioned to
use "48
or 72 hours after the problems was hit for the first time". That of
cause would need to be managed on the client (e.g. for each broken dep
write down somewhere when the problem showed up; if the same problem
shows up with the same packages 72 hours later then boil out to make
sure the user gets aware of the issue).
And what about when said build has spent a number of days in -testing,
and finally goes out to -final, then the build date is quite old, but
would be 'hit for the first time' by a larger number of people.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
1:04 p.m.
On 04.08.2008 19:25, Jesse Keating wrote:
On Mon, 2008-08-04 at 18:10 +0200, Thorsten Leemhuis wrote:
> That why I didn't suggest to use the build date and mentioned to use "48
> or 72 hours after the problems was hit for the first time". That of
> cause would need to be managed on the client (e.g. for each broken dep
> write down somewhere when the problem showed up; if the same problem
> shows up with the same packages 72 hours later then boil out to make
> sure the user gets aware of the issue).
Seems what I want to say is not what is understood on the other side (my
fault, not yours).
And what about when said build has spent a number of days in
-testing,
and finally goes out to -final, then the build date is quite old, but
would be 'hit for the first time' by a larger number of people.
The build date in totally irrelevant in the scheme I try to outline;
only the date when the problem itself is hit on the client machine for
the first time is.
Maybe two examples help to explain my thoughts better:
- new xine-lib hits fedora repos
- livna is late and has no matching xine-lib-extras-freeworld ready
- yum runs into dep trouble, as the locally installed
xine-lib-extras-freeworld still requires the old xine-lib
- "skip broken" says to yum "ignore xine-lib for now and install the
other updates; prints a warning"; in parallel it saves the current date
in time somewhere on the system
Now two variants can happen:
(a)
- some users notice that "skip broken" mentioned the dep issue and
report to livna
- livna quickly (say: within 48 hours) builds and ships the
xine-lib-extras-freeworld for the new xine-lib from Fedora
- that will solve the problem and the update will get installed next
time yum update get run by the user
-> user is happy; most won't even notice there were problems
(b)
- nobody notices the problem and nothing is done to fix it
- 72 hours later yum update is called again by the user;
- yum runs into the same dep trouble again that it hit 72 hours ago;
"skip broken" notices that and tell yum "boils out" -- just as yum
normally does today immediately if it runs into dep trouble
-> user unhappy, just as today; but it forces users to notice the
problem; they can do something to fix is to get the security update
IOW: we get a 72 hour long window where we can fix dep issues
(inter-repo or even dep issues within one repo) where the
mirror/different servers issues I outlined in my initial mail gets
silently ignored by yum on the client. If the problem remain for longer
we'll get the behavior we have today to make sure the user notices
there's a problem.
CU
knurd
5750
days inactive
5752
days old
18 comments
10 participants
participants (10)
-
Development discussions related to Fedora -
Jesse Keating -
John Ellson -
Kevin Kofler -
Mark -
Michael Schwendt -
Rex Dieter -
Seth Vidal -
Thorsten Leemhuis -
yersinia