RFC: best way to fix the regular yum dependency problems with add-on packages from 3rd party repositories
On Sat, Aug 2, 2008 at 3:41 PM, John Ellson <john.ellson@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?
> 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@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
08-02-2008, 05:41 PM
Rex Dieter
RFC: best way to fix the regular yum dependency problems with add-on packages from 3rd party repositories
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
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
08-03-2008, 09:04 PM
yersinia
RFC: best way to fix the regular yum dependency problems with add-on packages from 3rd party repositories
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@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
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
08-04-2008, 03:39 PM
Seth Vidal
RFC: best way to fix the regular yum dependency problems with add-on packages from 3rd party repositories
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
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
08-04-2008, 05:25 PM
Jesse Keating
RFC: best way to fix the regular yum dependency problems with add-on packages from 3rd party repositories
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
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
RFC: best way to fix the regular yum dependency problems with add-on packages from 3rd party repositories
