8:26 p.m.
Please see the list of my attempts to update my system to rawhide.
The thing that seems most incorrect is that rpm or yum do not report
correctly the packages that need to be excluded. Since there always
seems to be some dependency problem (one gets fixed but another one
stops the update) it would seem that a reliable way to determine which
packages to exclude would be very helpful and save time that can be put
to better use. thanks for any help,
Richard Hally
[root@localhost root]# yum upgrade
Gathering header information file(s) from server(s)
Server: Fedora Core 1 - i386 - Rawhide
Finding updated packages
Downloading needed headers
Finding obsoleted packages
Resolving dependencies
......Unable to satisfy dependencies
Package pwlib needs libdv.so.2, this is not available.
Package xemacs needs libRKC.so.1.2, this is not available.
Package xemacs needs libcanna.so.1.2, this is not available.
Package dvgrab needs libdv.so.2, this is not available.
Package db4-java needs db4 = 4.1.25-14, this is not available.
Here is the second attempt with the packages that reported excluded
[root@localhost root]# yum --exclude=pwlib --exclude=xemacs
--exclude=dvgrab --exclude=db4-java upgrade
Gathering header information file(s) from server(s)
Server: Fedora Core 1 - i386 - Rawhide
Finding updated packages
Downloading needed headers
Finding obsoleted packages
Resolving dependencies
......Unable to satisfy dependencies
Package gnomemeeting needs libpt.so.1.6.3, this is not available.
Package gnomemeeting needs pwlib >= 1.6.3, this is not available.
Package xemacs-info needs xemacs = 21.4.15, this is not available.
Package openh323 needs libpt.so.1.6.3, this is not available.
Package openh323 needs pwlib >= 1.6.3, this is not available.
Package xemacs-el needs xemacs = 21.4.15, this is not available.
Package pwlib-devel needs libpt.so.1.6.3, this is not available.
Package pwlib-devel needs pwlib = 1.6.3, this is not available.
Package db4-java needs db4 = 4.1.25-14, this is not available.
[root@localhost root]#
9:09 p.m.
Richard Hally wrote:
Please see the list of my attempts to update my system to rawhide.
The thing that seems most incorrect is that rpm or yum do not report
correctly the packages that need to be excluded. Since there always
seems to be some dependency problem (one gets fixed but another one
stops the update) it would seem that a reliable way to determine which
packages to exclude would be very helpful and save time that can be put
to better use. thanks for any help,
Richard Hally
1) Development and test releases never were supported and there is never
the expectation that upgrades will go smoothly all the time. We try our
best to prevent breakage whenever possible, but these things inevitably
periodically happen when you have dozens of developers working on many
interlocking pieces of the puzzle. We are working on improving the
standard processes to avoid more of these issues in the future, but
eliminating it completely may never happen.
2) apt-get upgrade (but not dist-upgrade) avoids the missing pieces
automatically. All the way through FC2 test1 to current rawhide it has
worked for me in not leaving a broken system. The current selinux
policy problem needs to be solved though. Panu have you communicated
with the selinux people about this?
Warren
12:22 a.m.
Warren Togami wrote:
Richard Hally wrote:
> Please see the list of my attempts to update my system to rawhide.
> The thing that seems most incorrect is that rpm or yum do not report
> correctly the packages that need to be excluded. Since there always
> seems to be some dependency problem (one gets fixed but another one
> stops the update) it would seem that a reliable way to determine
> which packages to exclude would be very helpful and save time that
> can be put to better use. thanks for any help,
> Richard Hally
1) Development and test releases never were supported and there is
never the expectation that upgrades will go smoothly all the time. We
try our best to prevent breakage whenever possible, but these things
inevitably periodically happen when you have dozens of developers
working on many interlocking pieces of the puzzle. We are working on
improving the standard processes to avoid more of these issues in the
future, but eliminating it completely may never happen.
2) apt-get upgrade (but not dist-upgrade) avoids the missing pieces
automatically. All the way through FC2 test1 to current rawhide it
has worked for me in not leaving a broken system. The current selinux
policy problem needs to be solved though. Panu have you communicated
with the selinux people about this?
Warren
Thanks Warren, I understand your 1) above, that is why it is important
to provide the mechanism to enable people to work around the problem in
a reasonably proficient manner.
I'll look into this apt-get , perhaps yet another "update mechanism"
will be the answer ;-)
p.s. I've been lurking on the SELinux list since early 2001 and my main
reason for getting involved with Fedora is to work on SELinux. Perhaps
I'll be able to "pick up a shovel" once I get past spending so much time
on this "dependency hell".
Thanks for your help,
Richard Hally
2:43 p.m.
On Sat, 2004-04-03 at 06:09, Warren Togami wrote:
2) apt-get upgrade (but not dist-upgrade) avoids the missing pieces
automatically. All the way through FC2 test1 to current rawhide it has
worked for me in not leaving a broken system. The current selinux
policy problem needs to be solved though. Panu have you communicated
with the selinux people about this?
The quick and dirty fix is to put apt-get, apt-shell and synaptic into
rpm_exec_t file context, eg apply this patch to the policy-sources and
relabel:
--- rpm.fc.orig 2004-04-05 22:28:45.000000000 +0300
+++ rpm.fc 2004-04-05 22:29:09.000000000 +0300
@@ -3,6 +3,9 @@
/var/lib(64)?/alternatives(/.*)? system_u:object_r:rpm_var_lib_t
/bin/rpm -- system_u:object_r:rpm_exec_t
/usr/bin/yum -- system_u:object_r:rpm_exec_t
+/usr/bin/apt-get -- system_u:object_r:rpm_exec_t
+/usr/bin/apt-shell -- system_u:object_r:rpm_exec_t
+/usr/bin/apt-synaptic -- system_u:object_r:rpm_exec_t
/usr/lib/rpm/rpmd -- system_u:object_r:bin_t
/usr/lib/rpm/rpmq -- system_u:object_r:bin_t
/usr/lib/rpm/rpmk -- system_u:object_r:bin_t
In the long run apt should probably run in it's own domain with suitable
restrictions on the methods etc... but this all raises the question:
How are 3rd party packages supposed to ship their own policy settings in
a sane manner?
- Panu -
5:35 a.m.
On Tue, 6 Apr 2004 05:43, Panu Matilainen <pmatilai(a)welho.com> wrote:
In the long run apt should probably run in it's own domain with
suitable
restrictions on the methods etc... but this all raises the question:
How are 3rd party packages supposed to ship their own policy settings in
a sane manner?
I've added rpm_exec_t entries for the apt programs in my tree.
If we are going to have apt as a recommended program or if we have some setup
with yum or up2date whereby one program gets the files and another does the
install (similar to the apt-get/dpkg) then we could write policy to
support/enforce that distinction.
However I expect apt to be phased out, so it's probably not worth doing.
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
6:25 a.m.
Russell Coker wrote:
On Tue, 6 Apr 2004 05:43, Panu Matilainen <pmatilai(a)welho.com>
wrote:
>In the long run apt should probably run in it's own domain with suitable
>restrictions on the methods etc... but this all raises the question:
>How are 3rd party packages supposed to ship their own policy settings in
>a sane manner?
I've added rpm_exec_t entries for the apt programs in my tree.
If we are going to have apt as a recommended program or if we have some setup
with yum or up2date whereby one program gets the files and another does the
install (similar to the apt-get/dpkg) then we could write policy to
support/enforce that distinction.
However I expect apt to be phased out, so it's probably not worth doing.
apt will not be phased out.
Warren
12:12 p.m.
On Sun, 11 Apr 2004, Russell Coker wrote:
On Tue, 6 Apr 2004 05:43, Panu Matilainen <pmatilai(a)welho.com>
wrote:
> In the long run apt should probably run in it's own domain with suitable
> restrictions on the methods etc... but this all raises the question:
> How are 3rd party packages supposed to ship their own policy settings in
> a sane manner?
I've added rpm_exec_t entries for the apt programs in my tree.
If we are going to have apt as a recommended program or if we have some setup
with yum or up2date whereby one program gets the files and another does the
install (similar to the apt-get/dpkg) then we could write policy to
support/enforce that distinction.
Note that apt-rpm by default doesn't use external rpm binary to do the
installation anymore, it uses rpmlib for the job (but can be reverted to
the old behavior with a config option). So in that mode it requires all
the rights rpm itself has.
The other parts like download, uncompress etc which run as separate
processes could well be restricted much more and I'm in fact planning to
write such a policy for apt just (if only to teach myself selinux).
However I expect apt to be phased out, so it's probably not worth doing.
I don't see it going away anytime soon.
- Panu -
1:56 a.m.
On Mon, 12 Apr 2004 03:12, Panu Matilainen <pmatilai(a)welho.com> wrote:
> If we are going to have apt as a recommended program or if we
have some
> setup with yum or up2date whereby one program gets the files and another
> does the install (similar to the apt-get/dpkg) then we could write policy
> to support/enforce that distinction.
Note that apt-rpm by default doesn't use external rpm binary to do the
installation anymore, it uses rpmlib for the job (but can be reverted to
the old behavior with a config option). So in that mode it requires all
the rights rpm itself has.
This isn't a problem. apt uses helper programs to do the actual download
which can be run in a context that has no privs to do the actual
installation. The rpmlib code called by the main apt process can verify the
integrity of the downloaded file.
Hmm, does rpmlib deal with the case of a .rpm file being signed, but then
being replaced between signature check and installation?
The other parts like download, uncompress etc which run as separate
processes could well be restricted much more and I'm in fact planning to
write such a policy for apt just (if only to teach myself selinux).
That's great!
> However I expect apt to be phased out, so it's probably not
worth doing.
I don't see it going away anytime soon.
So we will have both apt and yum doing much the same thing?
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
5 a.m.
On Apr 12, 2004, Russell Coker <russell(a)coker.com.au> wrote:
> > However I expect apt to be phased out, so it's probably
not worth doing.
>
> I don't see it going away anytime soon.
So we will have both apt and yum doing much the same thing?
We (Fedora Core) don't ship apt (ATM?), but there's no reason to make
the life of those who prefer apt over yum or up2date more difficult.
Especially after all of them switch to a common repository format.
And even more so considering that we don't have a GUI front-end for
Extras similar to synaptics (that I've never used myself, FWIW)
It's about choice. It's not like we should decide whether our users
should use Gnome or KDE; GNU Emacs or XEmacs or vim or whatever.
--
Alexandre Oliva http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer aoliva(a){redhat.com, gcc.gnu.org}
Free Software Evangelist oliva(a){lsd.ic.unicamp.br, gnu.org}
5:08 a.m.
On Mon, 12 Apr 2004 20:00, Alexandre Oliva <aoliva(a)redhat.com> wrote:
On Apr 12, 2004, Russell Coker <russell(a)coker.com.au> wrote:
>> > However I expect apt to be phased out, so it's probably not worth
>> > doing.
>>
>> I don't see it going away anytime soon.
>
> So we will have both apt and yum doing much the same thing?
We (Fedora Core) don't ship apt (ATM?), but there's no reason to make
the life of those who prefer apt over yum or up2date more difficult.
Especially after all of them switch to a common repository format.
And even more so considering that we don't have a GUI front-end for
Extras similar to synaptics (that I've never used myself, FWIW)
It's about choice. It's not like we should decide whether our users
should use Gnome or KDE; GNU Emacs or XEmacs or vim or whatever.
True, we want to give choice. But when deciding how much work we want to
spend on supporting one particular choice we have to think about how much use
it's going to get. I was under the impression that yum was the preferred
choice as apt was designed to work best for Debian packages with separate
install and configure stages etc.
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
8:58 a.m.
On Mon, 12 Apr 2004, Russell Coker wrote:
On Mon, 12 Apr 2004 20:00, Alexandre Oliva <aoliva(a)redhat.com>
wrote:
> On Apr 12, 2004, Russell Coker <russell(a)coker.com.au> wrote:
> >> > However I expect apt to be phased out, so it's probably not worth
> >> > doing.
> >>
> >> I don't see it going away anytime soon.
> >
> > So we will have both apt and yum doing much the same thing?
>
> We (Fedora Core) don't ship apt (ATM?), but there's no reason to make
> the life of those who prefer apt over yum or up2date more difficult.
> Especially after all of them switch to a common repository format.
> And even more so considering that we don't have a GUI front-end for
> Extras similar to synaptics (that I've never used myself, FWIW)
>
> It's about choice. It's not like we should decide whether our users
> should use Gnome or KDE; GNU Emacs or XEmacs or vim or whatever.
True, we want to give choice. But when deciding how much work we want to
spend on supporting one particular choice we have to think about how much use
it's going to get. I was under the impression that yum was the preferred
choice as apt was designed to work best for Debian packages with separate
install and configure stages etc.
Apt was designed to be package format independent from the start, it just
took a while before rpm-support was added. And yes, certain amount of
debianisms exist in there but separate install/configure stages have
preciously little to do with anything, apt-rpm simply doesn't have a
"configure" stage.
For basic updating and installing packages it's pretty much irrelevant
whether you use apt, up2date, yum, red-carpet or whatever, they all
get the job done. Apt has some nice things for developers, like installing
build dependencies of a given package, retrieve and install + optionally
build src.rpm's. It also has an embedded scripting language which allows
all sorts of cool things like adding new commands and customizing apt
behavior without having to touch apt's code at all - for example of this
check out the mirror-selector system in fedora.us apt. In short - it does
some things that the other depsolvers don't (currently) and lots of people
happen to like those features :)
- Panu -
5:58 a.m.
On Mon, 12 Apr 2004 16:56:00 +1000, Russell Coker wrote:
> > However I expect apt to be phased out, so it's probably
not worth doing.
>
> I don't see it going away anytime soon.
So we will have both apt and yum doing much the same thing?
Don't forget Synaptic. Actually, as a graphical front-end to APT-RPM
and as an alternative to system-config-packages, it's quite popular.
2:04 a.m.
On Fri, 2004-04-02 at 21:26 -0500, Richard Hally wrote:
Please see the list of my attempts to update my system to rawhide.
The thing that seems most incorrect is that rpm or yum do not report
correctly the packages that need to be excluded. Since there always
seems to be some dependency problem (one gets fixed but another one
stops the update) it would seem that a reliable way to determine which
packages to exclude would be very helpful and save time that can be put
to better use. thanks for any help,
Richard Hally
> [root@localhost root]# yum upgrade
<snip>
> Package pwlib needs libdv.so.2, this is not available.
> Package xemacs needs libRKC.so.1.2, this is not available.
> Package xemacs needs libcanna.so.1.2, this is not available.
> Package dvgrab needs libdv.so.2, this is not available.
> Package db4-java needs db4 = 4.1.25-14, this is not available.
<snip>
> [root@localhost root]# yum --exclude=pwlib --exclude=xemacs
> --exclude=dvgrab --exclude=db4-java upgrade
You have, like so many others, misunderstood the statements: they are
not telling you what packages are not available, they are telling you
what files are no longer available (due to the new version being
installed--libraries are being removed/updated).
libdv.so.2 is being removed, the new version of libdv does NOT supply
it, likewise for the other files mentioned. This is accurately telling
you what files are no longer present after the test upgrade (dependency
tests).
You should have instead excluded the library packages that were being
changed, not the packages you already have that require the old library
files. What you did was to exclude packages which you already have
installed--essentially doing nothing.
You may need to remove db4-java since that package requires an old
library (or find the update to it which should be built properly against
the new library).
yum --exclude=libdv* --exclude=Canna-lib* --exclude=db4 update
--
Andrew J Farris
afarris(a)calpoly.edu :: andrew(a)andrewfarris.com
California Polytechnic State University, San Luis Obispo CA
http://www.andrewfarris.com/
3:02 a.m.
Andrew Farris wrote:
On Fri, 2004-04-02 at 21:26 -0500, Richard Hally wrote:
>Please see the list of my attempts to update my system to rawhide.
>The thing that seems most incorrect is that rpm or yum do not report
>correctly the packages that need to be excluded. Since there always
>seems to be some dependency problem (one gets fixed but another one
>stops the update) it would seem that a reliable way to determine which
>packages to exclude would be very helpful and save time that can be put
>to better use. thanks for any help,
>Richard Hally
>
>
>
>
>
>>[root@localhost root]# yum upgrade
>>
>>
<snip>
>>Package pwlib needs libdv.so.2, this is not available.
>>Package xemacs needs libRKC.so.1.2, this is not available.
>>Package xemacs needs libcanna.so.1.2, this is not available.
>>Package dvgrab needs libdv.so.2, this is not available.
>>Package db4-java needs db4 = 4.1.25-14, this is not available.
>>
>>
<snip>
>>[root@localhost root]# yum --exclude=pwlib --exclude=xemacs
>>--exclude=dvgrab --exclude=db4-java upgrade
>>
>>
You have, like so many others, misunderstood the statements: they are
not telling you what packages are not available, they are telling you
what files are no longer available (due to the new version being
installed--libraries are being removed/updated).
libdv.so.2 is being removed, the new version of libdv does NOT supply
it, likewise for the other files mentioned. This is accurately telling
you what files are no longer present after the test upgrade (dependency
tests).
You should have instead excluded the library packages that were being
changed, not the packages you already have that require the old library
files. What you did was to exclude packages which you already have
installed--essentially doing nothing.
You may need to remove db4-java since that package requires an old
library (or find the update to it which should be built properly against
the new library).
yum --exclude=libdv* --exclude=Canna-lib* --exclude=db4 update
Thank you Andrew, you make my point for me in an indrect way. It takes
four paragraphs to try to explain what is going on and it is still as
clear as mud(no slam on your excellent exposition). I just want it to
tell me what packages to exclude, that's all. :)
But, to extend the instance, the result of your suggested yum command
line is shown below:
(I have installed apt since the previous attempt with yum (of course
that just adds to the problem))
Isn't that just wonderful...and it goes on, rpm-4.2.1-0.30 is
installed and provides librpm-4.2.so
but of course yum/rpm doesn't say it will not be available if I do this
update, it says *is not *available. should I add --exclude=rpm
--exclude=python2.2
I guess I have belabored the point, sorry
Thanks for your help,
Richard Hally
[root@localhost root]# yum --exclude=libdv* --exclude=Canna-lib
--exclude=db4 update
Gathering header information file(s) from server(s)
Server: Fedora Core 1 - i386 - Rawhide
Finding updated packages
Downloading needed headers
Resolving dependencies
.Package apt needs librpm-4.2.so, this is not available.
Package apt needs librpmdb-4.2.so, this is not available.
Package apt needs librpmio-4.2.so, this is not available.
Package db4-java needs db4 that has been excluded.
Package redhat-config-network-tui needs /usr/bin/python2.2, this is not
available.
Package redhat-config-users needs /usr/bin/python2.2, this is not
available.
Package redhat-config-nfs needs /usr/bin/python2.2, this is not available.
Package redhat-config-language needs /usr/bin/python2.2, this is not
available.
Package redhat-config-xfree86 needs /usr/bin/python2.2, this is not
available.
Package redhat-config-kickstart needs /usr/bin/python2.2, this is not
available.Package redhat-config-date needs /usr/bin/python2.2, this is
not available.
Package redhat-config-keyboard needs /usr/bin/python2.2, this is not
available.
Package redhat-config-mouse needs /usr/bin/python2.2, this is not
available.
Package redhat-config-securitylevel needs /usr/bin/python2.2, this is
not available.
Package redhat-config-soundcard needs /usr/bin/python2.2, this is not
available.Package redhat-config-samba needs /usr/bin/python2.2, this is
not available.
Package redhat-config-bind needs /usr/bin/python2.2, this is not available.
Package redhat-config-rootpassword needs /usr/bin/python2.2, this is not
available.
[root@localhost root]#
4:06 a.m.
On Sat, 2004-04-03 at 11:02, Richard Hally wrote:
[root@localhost root]# yum --exclude=libdv* --exclude=Canna-lib
--exclude=db4 update
Gathering header information file(s) from server(s)
Server: Fedora Core 1 - i386 - Rawhide
Finding updated packages
Downloading needed headers
Resolving dependencies
.Package apt needs librpm-4.2.so, this is not available.
Package apt needs librpmdb-4.2.so, this is not available.
Package apt needs librpmio-4.2.so, this is not available.
Package db4-java needs db4 that has been excluded.
Package redhat-config-network-tui needs /usr/bin/python2.2, this is not
available.
Package redhat-config-users needs /usr/bin/python2.2, this is not
available.
Package redhat-config-nfs needs /usr/bin/python2.2, this is not available.
Package redhat-config-language needs /usr/bin/python2.2, this is not
available.
Package redhat-config-xfree86 needs /usr/bin/python2.2, this is not
available.
Package redhat-config-kickstart needs /usr/bin/python2.2, this is not
available.Package redhat-config-date needs /usr/bin/python2.2, this is
not available.
Package redhat-config-keyboard needs /usr/bin/python2.2, this is not
available.
Package redhat-config-mouse needs /usr/bin/python2.2, this is not
available.
Package redhat-config-securitylevel needs /usr/bin/python2.2, this is
not available.
Package redhat-config-soundcard needs /usr/bin/python2.2, this is not
available.Package redhat-config-samba needs /usr/bin/python2.2, this is
not available.
Package redhat-config-bind needs /usr/bin/python2.2, this is not available.
Package redhat-config-rootpassword needs /usr/bin/python2.2, this is not
available.
[root@localhost root]#
All redhat-config-* packages have been superseded and obsoleted by
system-config-* packages. I think you will need to manually remove any
redhat-config-* package and install their equivalent system-config-*
ones.
5:28 a.m.
yes, I have run into these issues before. It helps to run `yum list
extras` to see which packages are installed, but are not in the yum.conf
repositories (removed in some cases such as the redhat-config-*). I do
not think that running yum upgrade would replace the redhat-config-* with
the appropriate system-config-* packages. Hope that idea clears up some
of the problems. I rarely get broken package upgrading these
after-extras-removed days :) (though libdv and the ethereal bugs did just
happen, they are the exception rather than the rule I think.)
---Matt
<reactivate lurk mode>
On Sat, 2004-04-03 at 11:02, Richard Hally wrote:
>
> [root@localhost root]# yum --exclude=libdv* --exclude=Canna-lib
> --exclude=db4 update
> Gathering header information file(s) from server(s)
> Server: Fedora Core 1 - i386 - Rawhide
> Finding updated packages
> Downloading needed headers
> Resolving dependencies
> .Package apt needs librpm-4.2.so, this is not available.
> Package apt needs librpmdb-4.2.so, this is not available.
> Package apt needs librpmio-4.2.so, this is not available.
> Package db4-java needs db4 that has been excluded.
> Package redhat-config-network-tui needs /usr/bin/python2.2, this is not
> available.
> Package redhat-config-users needs /usr/bin/python2.2, this is not
> available.
> Package redhat-config-nfs needs /usr/bin/python2.2, this is not
> available.
> Package redhat-config-language needs /usr/bin/python2.2, this is not
> available.
> Package redhat-config-xfree86 needs /usr/bin/python2.2, this is not
> available.
> Package redhat-config-kickstart needs /usr/bin/python2.2, this is not
> available.Package redhat-config-date needs /usr/bin/python2.2, this is
> not available.
> Package redhat-config-keyboard needs /usr/bin/python2.2, this is not
> available.
> Package redhat-config-mouse needs /usr/bin/python2.2, this is not
> available.
> Package redhat-config-securitylevel needs /usr/bin/python2.2, this is
> not available.
> Package redhat-config-soundcard needs /usr/bin/python2.2, this is not
> available.Package redhat-config-samba needs /usr/bin/python2.2, this is
> not available.
> Package redhat-config-bind needs /usr/bin/python2.2, this is not
> available.
> Package redhat-config-rootpassword needs /usr/bin/python2.2, this is not
> available.
> [root@localhost root]#
All redhat-config-* packages have been superseded and obsoleted by
system-config-* packages. I think you will need to manually remove any
redhat-config-* package and install their equivalent system-config-*
ones.
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
http://www.redhat.com/mailman/listinfo/fedora-devel-list
8:26 a.m.
On Sat, 2004-04-03 at 06:28 -0500, mmundy1(a)umbc.edu wrote:
yes, I have run into these issues before. It helps to run `yum
list
extras` to see which packages are installed, but are not in the yum.conf
repositories (removed in some cases such as the redhat-config-*). I do
not think that running yum upgrade would replace the redhat-config-* with
the appropriate system-config-* packages.
yum upgrade will replace the redhat-config-* with system-config-*
-sv
8:26 a.m.
All redhat-config-* packages have been superseded and obsoleted by
system-config-* packages. I think you will need to manually remove any
redhat-config-* package and install their equivalent system-config-*
ones.
running 'yum upgrade' will take care of the obsoleted packages.
-sv
7376
days inactive
7385
days old
18 comments
12 participants
participants (12)
-
Alexandre Oliva -
Andrew Farris -
Felipe Alfaro Solana -
Markus Bertheau -
Matthew Mundy -
Michael Schwendt -
Panu Matilainen -
Richard Hally -
Richard Hally -
Russell Coker -
seth vidal -
Warren Togami