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 Development

 
 
LinkBack Thread Tools
 
Old 08-02-2008, 12:21 PM
Thorsten Leemhuis
 
Default RFC: best way to fix the regular yum dependency problems with add-on packages from 3rd party repositories

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

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 08-02-2008, 01:41 PM
John Ellson
 
Default RFC: best way to fix the regular yum dependency problems with add-on packages from 3rd party repositories

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




--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 08-02-2008, 02:05 PM
Michael Schwendt
 
Default RFC: best way to fix the regular yum dependency problems with add-on packages from 3rd party repositories

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@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 08-02-2008, 02:09 PM
Thorsten Leemhuis
 
Default RFC: best way to fix the regular yum dependency problems with add-on packages from 3rd party repositories

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

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 08-02-2008, 02:34 PM
John Ellson
 
Default RFC: best way to fix the regular yum dependency problems with add-on packages from 3rd party repositories

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

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 08-02-2008, 02:36 PM
Michael Schwendt
 
Default RFC: best way to fix the regular yum dependency problems with add-on packages from 3rd party repositories

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

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 08-02-2008, 02:47 PM
David Timms
 
Default RFC: best way to fix the regular yum dependency problems with add-on packages from 3rd party repositories

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.

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 08-02-2008, 04:59 PM
Michael Schwendt
 
Default RFC: best way to fix the regular yum dependency problems with add-on packages from 3rd party repositories

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

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 08-03-2008, 06:57 AM
Thorsten Leemhuis
 
Default RFC: best way to fix the regular yum dependency problems with add-on packages from 3rd party repositories

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

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 08-03-2008, 07:07 AM
Michael Schwendt
 
Default RFC: best way to fix the regular yum dependency problems with add-on packages from 3rd party repositories

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.

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 

Thread Tools




All times are GMT. The time now is 11:41 PM.

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