From: Thomas de Grenier de Latour <degrenier@easyconnect.fr>
To: gentoo-dev@gentoo.org
Subject: Re: [gentoo-dev] uninstalling packages with portage
Date: Wed, 27 Aug 2003 09:11:24 +0200 [thread overview]
Message-ID: <20030827091124.23079e69.degrenier@easyconnect.fr> (raw)
In-Reply-To: <a05210605bb71fe411ea2@[10.96.0.12]>
On Wed, 27 Aug 2003 02:24:37 -0400
Rajiv Aaron Manglani <rajiv@gentoo.org> wrote:
> >The netkit-base ebuild no longer provides ping (iputils provides a
> >much better ping)
>
> how about this one:
>
> $ qpkg -f /etc/mailcap
> net-mail/mailbase *
> net-mail/pine *
>
I also want to play :)
for f in $( find /var/db/pkg -name "CONTENTS" -exec cat {} \; | awk
'/^obj/ { print $2 " " $3 }' | grep -v "^/var" | sort | uniq | awk '{
print $1 }' | uniq -d ) ; do echo "--- ${f}:" ; qpkg -nc -f -I -v ${f} ;
echo ; done
Basically, it will list files that have several owners registered in the
packages db. The result were really huge here (but the box is 18 months
old, with regular deep updates). Here is a summary:
* Slot duplicates:
Correct me if I'm wrong, but imho too versions of a package in different
slots should not share files. If they do, then your system will start to
depend on the order in which you have made installations/updates (which
is already somehow true because of libs, but only concerns those that
are not important enough to be deps, whereas here it may overide some
explicit user choices). And if at some point portage allows in slots
updates, results may be very bizarre on some machine.
- The biggest part of my duplicates are because of old unslotted
packages that were never cleaned by portage. This was easy to clean up
(I've written a small script to force empty slot to same value as the
smallest greater version of the package. May not be perfect, but
saved some time.)
- Another part is because of funky packages reslotting between similar
versions (like "2.0" -> "2"), this kind of things. Don't take me wrong,
I understand that devs sometimes want to polish their ebuilds, but I
also think new slots should only be introduced when it is really
necessary. As I don't like to see all this outdated things in my pkg db,
I've made some manual clean here.
- Then come what I would call real slotting bug: linux-headers is one
(see bug #26460), but I've also seen also at least bug-buddy, guile,
and orbit2 which use different slots whereas some files at a same
location.
* Real packages duplicates:
Good news, there is big issue on my list:
- openmotif vs. lesstif: a well known one. Almost all files are in both
packages. I would vote for a mutual exclusion, because it doesn't
makes sense to have both installed (one breaks the other). And in case
of updates, the user will sometimes get lesstif, sometimes openmotif...
(and don't ask why both where installed on my system, I have no idea)
- net-analyzer/net-snmp-5.0.8 vs. net-analyzer/ucd-snmp-4.2.6-r1
(virtual/snmp): Same here. Shouldn't they be mutual exclusive?
- net-mail/mailbase-0.00-r6 vs. net-p2p/bittorrent-3.2.1b-r4 on
/etc/mailcap: This mailcap stuff really seems popular... Would be
nice to have only one package (mailbase?) which provides it, and the
others (bittorrent an pine) depends on it.
- sys-apps/coreutils-5.0-r2 vs. sys-apps/shadow-4.0.3-r7 on /bin/groups
(is it supposed to be the same program in both
packages?)
- dev-tcltk/expect-5.37.1-r1 vs. net-misc/whois-4.6.6-r2 on
/usr/bin/mkpasswd (same question)
- sys-apps/coreutils-5.0-r2 vs. sys-apps/procps-3.1.11 vs.
sys-apps/util-linux-2.12 on /bin/kill (already discussed)
- sys-devel/gcc-2.95.3-r8 vs. sys-devel/gcc-config-1.3.3-r1 on
/lib/cpp. I guess it's well intentional?
- app-admin/etcat-0.1 vs. app-portage/gentoolkit-0.1.30: couldn't the
separate package (etcat) be removed?
- app-text/html-xml-utils-2.3-r1 vs. media-sound/normalize-0.7.6-r1 on
/usr/bin/normalize: Doh! I guess this two ones are not that related... I
think this one is really a bug, I will submit it.
- several perl modules vs. perl-5.8: I guess it's normal.
- dev-libs/libusb-0.1.7 vs. sys-apps/usbutils-0.11-r1 on
/usr/lib/libusb.la
- dev-python/gnome-python-1.4.4 vs. dev-python/pygtk-1.99.17
(Could be an issue, since both packages are used by some apps. But I've
not checked if the files were supposed to be really different or just
duplicates of the same code.)
- sys-devel/binutils-2.14.90.0.6-r1 vs. sys-devel/gdb-5.3 on some info
files (Who cares?...)
- lots of duplicates on manpages, mainly coreutils vs. the rest of the
world (Again, not a real issue)
And that's all, this mail is long enough, I don't have a conclusion :)
--
TGL.
--
gentoo-dev@gentoo.org mailing list
next prev parent reply other threads:[~2003-08-27 7:07 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-08-26 22:58 [gentoo-dev] uninstalling packages with portage Andrew Gaffney
2003-08-26 23:02 ` Cedric Veilleux
2003-08-26 23:14 ` Andrew Gaffney
2003-08-26 23:01 ` Stuart Herbert
2003-08-26 23:19 ` Georgi Georgiev
2003-08-27 0:08 ` Michael Cummings
2003-08-27 0:15 ` Jon Portnoy
2003-08-27 0:32 ` Michael Cummings
2003-08-27 0:37 ` Jon Portnoy
2003-08-27 8:27 ` Mikael Andersson
2003-08-27 8:37 ` Jason Stubbs
2003-08-27 6:24 ` Rajiv Aaron Manglani
2003-08-27 7:11 ` Thomas de Grenier de Latour [this message]
2003-08-27 7:27 ` Jon Portnoy
2003-08-27 7:53 ` Thomas de Grenier de Latour
2003-08-27 8:00 ` Jon Portnoy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20030827091124.23079e69.degrenier@easyconnect.fr \
--to=degrenier@easyconnect.fr \
--cc=gentoo-dev@gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox