[gentoo-user] Removing Packages with Portage

[gentoo-user] Removing Packages with Portage

[Matt Causey]

Hello all!

I am a Gentoo n00b.  I have  question about what the 'expected
behaviour' is/should be when removing packages under Gentoo package
management.  So I read this document:

http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?style=printable&full=1#book_part2

And it says, to remove software, use  'emerge --unmerge'.  Cool, yeah
that seems to do what I expect... So, I have a package madwifi-ng,
which contains some kernel modules.  I want to emerge --unmerge that
package, because I want to make those drivers go away.  That seems to
go well, as when I search for it in portage it show all non-installed
and stuff:

prometheus ~ # emerge --search madwifi-ng
Searching...
[ Results for search key : madwifi-ng ]
[ Applications found : 2 ]

*  net-wireless/madwifi-ng
      Latest version available: 0.9.4
      Latest version installed: [ Not Installed ]
      Size of files: 3,403 kB
      Homepage:      http://www.madwifi-project.org/
      Description:   Next Generation driver for Atheros based IEEE
802.11a/b/g wireless LAN cards
      License:       atheros-hal || ( BSD GPL-2 )

Buuut, there are still kernel modules there, which are owned by that package:

prometheus ~ # ls -lah /lib/modules/2.6.28-gentoo-r5/net/ath_pci.ko
-rw-r--r-- 1 root root 77K May  3 20:43
/lib/modules/2.6.28-gentoo-r5/net/ath_pci.ko
prometheus ~ #

and of course they still load.

Sooo, my question.  What is the expected behaviour here?  Are the
ebuilds intended to maintain knowledge of the files they put on a
system, so they can remove the binaries when --unmerge'd?  Are kernel
modules handled differently because of the possibility of damaging a
working system?

Thanks!

--
Matt

Re: [gentoo-user] Removing Packages with Portage

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 663 bytes --]

On Mon, 4 May 2009 10:45:00 +0100, Matt Causey wrote:

> Sooo, my question.  What is the expected behaviour here?  Are the
> ebuilds intended to maintain knowledge of the files they put on a
> system, so they can remove the binaries when --unmerge'd?  Are kernel
> modules handled differently because of the possibility of damaging a
> working system?

The latter. The user programs will be gone but the kernel modules stay.
With more "normal" packages, the only files that are not removed are
those in CONFIG_PROTECTed directories and those that have been modified
since installation.


-- 
Neil Bothwick

Out of body, be back in five minutes.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Removing Packages with Portage

[KH]

Neil Bothwick schrieb:
> On Mon, 4 May 2009 10:45:00 +0100, Matt Causey wrote:
> 
>> Sooo, my question.  What is the expected behaviour here?  Are the
>> ebuilds intended to maintain knowledge of the files they put on a
>> system, so they can remove the binaries when --unmerge'd?  Are kernel
>> modules handled differently because of the possibility of damaging a
>> working system?
> 
> The latter. The user programs will be gone but the kernel modules stay.
> With more "normal" packages, the only files that are not removed are
> those in CONFIG_PROTECTed directories and those that have been modified
> since installation.
> 
> 

Anyway you also might want to run an emerge --depclean -av after
unmerging. Maybe there are othere programs not needed anymore at now.

kh

Re: [gentoo-user] Removing Packages with Portage

[Alan McKinnon]

On Monday 04 May 2009 11:45:00 Matt Causey wrote:
> Hello all!
>
> I am a Gentoo n00b.  I have  question about what the 'expected
> behaviour' is/should be when removing packages under Gentoo package
> management.  So I read this document:
>
> http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?style=printable&full
>=1#book_part2
>
> And it says, to remove software, use  'emerge --unmerge'.  Cool, yeah
> that seems to do what I expect... So, I have a package madwifi-ng,
> which contains some kernel modules.  I want to emerge --unmerge that
> package, because I want to make those drivers go away.  That seems to
> go well, as when I search for it in portage it show all non-installed
> and stuff:
>
> prometheus ~ # emerge --search madwifi-ng
> Searching...
> [ Results for search key : madwifi-ng ]
> [ Applications found : 2 ]
>
> *  net-wireless/madwifi-ng
>       Latest version available: 0.9.4
>       Latest version installed: [ Not Installed ]
>       Size of files: 3,403 kB
>       Homepage:      http://www.madwifi-project.org/
>       Description:   Next Generation driver for Atheros based IEEE
> 802.11a/b/g wireless LAN cards
>       License:       atheros-hal || ( BSD GPL-2 )
>
> Buuut, there are still kernel modules there, which are owned by that
> package:
>
> prometheus ~ # ls -lah /lib/modules/2.6.28-gentoo-r5/net/ath_pci.ko
> -rw-r--r-- 1 root root 77K May  3 20:43
> /lib/modules/2.6.28-gentoo-r5/net/ath_pci.ko
> prometheus ~ #
>
> and of course they still load.
>
> Sooo, my question.  What is the expected behaviour here?  Are the
> ebuilds intended to maintain knowledge of the files they put on a
> system, so they can remove the binaries when --unmerge'd?  

That's the general idea. Except for *this* case :-)

> Are kernel
> modules handled differently because of the possibility of damaging a
> working system?

Out of tree kernel modules are a maintenance pain in the ass, and cause 
severely non-obvious problems like this. Every time you upgrade your kernel, 
you must rebuild the out-of-tree modules, and you do that by re-running 
"emerge madwifi-ng". This builds a new modules that matches the currently 
configured kernel (/usr/src/linux/) and puts the module in 
/lib/modules/<version>

Upgrade your kernel a few times and you have various versions of modules 
floating around. Portage remembers the modules installed by the most recent 
emerge, but AFAIK forgets all the previous ones. This is expected of course - 
when you upgrade firefox-2 to firefox-3 you would not expect the system to 
remember the firefox-2 files (as they are supposed to not be there anymore)

-- 
alan dot mckinnon at gmail dot com

Re: [gentoo-user] Removing Packages with Portage

[Matt Causey]

> Out of tree kernel modules are a maintenance pain in the ass, and cause
> severely non-obvious problems like this. Every time you upgrade your kernel,
> you must rebuild the out-of-tree modules, and you do that by re-running
> "emerge madwifi-ng". This builds a new modules that matches the currently
> configured kernel (/usr/src/linux/) and puts the module in
> /lib/modules/<version>
>
> Upgrade your kernel a few times and you have various versions of modules
> floating around. Portage remembers the modules installed by the most recent
> emerge, but AFAIK forgets all the previous ones. This is expected of course -
> when you upgrade firefox-2 to firefox-3 you would not expect the system to
> remember the firefox-2 files (as they are supposed to not be there anymore)

Your explanation is extremely helpful here.  Thanks!  As long as I
know the expectation, I can plan for it when troubleshooting.  I can
certainly see the 'pain in the ass' factor there.  :-)  I was
originally chasing a panic caused by ath_pci - but now that I've
looked more closely at the issue that you describe here, I see that I
did manage to get 2 incompatible interdependent modules installed in
the system...grrr.  I'll be doing some more-than-casual tinkering with
ath_pci vs ath5k in the coming weeks, so I'll probably just plan not
to use that ebuild for the present moment.  :-)  Although....would it
be non-trivial for me to try and extend the ebuild to make it clean up
after itself on unmerge?

Along the same lines, how does the ebuild know what to remove on
--unmerge?  For example I'm wandering around and looking at ebuilds:

prometheus ethtool # pwd
/usr/portage/sys-apps/ethtool
prometheus ethtool # ls
ChangeLog  Manifest  ethtool-6.ebuild  metadata.xml
prometheus ethtool #

I see nothing in that ebuild which describes the files that ethtool
put on the system.  Yet an --unmerge removes the binaries and
source....interesting.

So I found a CONTENTS file:

prometheus ethtool-6 # pwd
/var/db/pkg/sys-apps/ethtool-6
prometheus ethtool-6 # cat CONTENTS
dir /usr
dir /usr/sbin
obj /usr/sbin/ethtool e830749ff2f81cc25b6629b19e93e3e7 1241002052
dir /usr/share
dir /usr/share/doc
dir /usr/share/doc/ethtool-6
obj /usr/share/doc/ethtool-6/NEWS.bz2 8757829b0fb19bb74c968c203fc76b68
1241002049
obj /usr/share/doc/ethtool-6/AUTHORS.bz2
11b48a9d12c1cebcb2ae6bb29e80d1e1 1241002049
obj /usr/share/doc/ethtool-6/ChangeLog.bz2
08b981d7a1afb29bbac1636ae81026c2 1241002049
obj /usr/share/doc/ethtool-6/README.bz2
3188a9ad571f7e4e4d0c1df4479db6d4 1241002049
dir /usr/share/man
dir /usr/share/man/man8
obj /usr/share/man/man8/ethtool.8.bz2 71a609e8a269cc9dcc0e813e77675ab6
1241002049
prometheus ethtool-6 #

Based on this, it looks like portage internally records the files
which get installed.....and then can retrieve this information later
(qfile might want this information, --unmerge might want it...etc.).
Is this the correct way to understand how portage maintains sanity?

Thanks!

--
Matt

Re: [gentoo-user] Removing Packages with Portage

[Alan McKinnon]

On Monday 04 May 2009 14:11:02 Matt Causey wrote:
> > Out of tree kernel modules are a maintenance pain in the ass, and cause
> > severely non-obvious problems like this. Every time you upgrade your
> > kernel, you must rebuild the out-of-tree modules, and you do that by
> > re-running "emerge madwifi-ng". This builds a new modules that matches
> > the currently configured kernel (/usr/src/linux/) and puts the module in
> > /lib/modules/<version>
> >
> > Upgrade your kernel a few times and you have various versions of modules
> > floating around. Portage remembers the modules installed by the most
> > recent emerge, but AFAIK forgets all the previous ones. This is expected
> > of course - when you upgrade firefox-2 to firefox-3 you would not expect
> > the system to remember the firefox-2 files (as they are supposed to not
> > be there anymore)
>
> Your explanation is extremely helpful here.  Thanks!  As long as I
> know the expectation, I can plan for it when troubleshooting.  I can
> certainly see the 'pain in the ass' factor there.  :-)  I was
> originally chasing a panic caused by ath_pci - but now that I've
> looked more closely at the issue that you describe here, I see that I
> did manage to get 2 incompatible interdependent modules installed in
> the system...grrr.

Love gotta love gentoo - break it, you get to keep both pieces :-)

> I'll be doing some more-than-casual tinkering with
> ath_pci vs ath5k in the coming weeks, so I'll probably just plan not
> to use that ebuild for the present moment.  :-)  Although....would it
> be non-trivial for me to try and extend the ebuild to make it clean up
> after itself on unmerge?
"
Portage keeps it's house-keeping in /var/db/pkg with subdirectories in the 
form <category>/<package>-<version>. There's interesting stuff in there, like 
a file called CONTENTS. It has the files installed by the ebuild, plus their 
md5sums, and that's how portage knows what to rm when you unmerge.

"man ebuild" lists the functions you can override in ebuilds, including 
unmerge. It calls pkg_postrm (a simple bash function) so you could in theory 
insert a call to "find /lib/modules" to find all the modules in question and 
delete them. You'd have to think this through carefully though as the 
potential for destruction is vast...

> Along the same lines, how does the ebuild know what to remove on
> --unmerge?  For example I'm wandering around and looking at ebuilds:
>
> prometheus ethtool # pwd
> /usr/portage/sys-apps/ethtool
> prometheus ethtool # ls
> ChangeLog  Manifest  ethtool-6.ebuild  metadata.xml
> prometheus ethtool #
>
> I see nothing in that ebuild which describes the files that ethtool
> put on the system.  Yet an --unmerge removes the binaries and
> source....interesting.

Portage runs the ebuild in a restricted directory - 
/var/tmp/portage/<category>/<package>/<work>/ and all the built files end up 
there, in a directory structure that mirrors the root filesystem layout. 

"man ebuild" has all the gory details. Try this: run 
"ebuild /usr/portage/sys-apps/ethtool-6.ebuild install"
and examine /var/tmp/portage/sys-apps/ethtool/work.

Note that you emerge a *package name* but ebuild an ebuild *file* (much the 
same way yum install and rpm -ivh do it). That command will run all the ebuild 
steps up to and including install, but the files are not yet on the lie 
filesystem. "ebuild <file> merge" does that, skipping all steps already 
completed. It then locates every file in the tmp directory and moves them onto 
the live filesystem, recording what it finds. This list is what goes in 
CONTENTS.

Simple, hey?

Virtually every tool out there which gives you information on installed 
packages (except eix, that also uses huge chunks of voodoo), looks in 
/var/db/pkg/, which explains why it's so slow - 1462 directories and 35847 
files on this box is a lot of stuff to stat and read

-- 
alan dot mckinnon at gmail dot com

Re: [gentoo-user] Removing Packages with Portage

[Daniel Iliev]

On Mon, 4 May 2009 13:11:02 +0100
Matt Causey <matt.causey@gmail.com> wrote:

--snip--

> 
> Along the same lines, how does the ebuild know what to remove on
> --unmerge?  For example I'm wandering around and looking at ebuilds:
> 
> prometheus ethtool # pwd
> /usr/portage/sys-apps/ethtool
> prometheus ethtool # ls
> ChangeLog  Manifest  ethtool-6.ebuild  metadata.xml
> prometheus ethtool #
> 
> I see nothing in that ebuild which describes the files that ethtool
> put on the system.  Yet an --unmerge removes the binaries and
> source....interesting.
> 
> So I found a CONTENTS file:
> 
> prometheus ethtool-6 # pwd
> /var/db/pkg/sys-apps/ethtool-6
> prometheus ethtool-6 # cat CONTENTS
> dir /usr
> dir /usr/sbin

--snip--


Another way to check which files are installed by a given package
and to which package a given file belongs.

emerge app-portage/portage-utils (if you haven't already)

Example:

~ $ qlist ethtool
/usr/share/man/man8/ethtool.8.bz2
/usr/share/doc/ethtool-6/AUTHORS.bz2
/usr/share/doc/ethtool-6/ChangeLog.bz2
/usr/share/doc/ethtool-6/NEWS.bz2
/usr/share/doc/ethtool-6/README.bz2
/usr/sbin/ethtool
~ $

~ $ qfile ethtool
sys-apps/ethtool (/usr/sbin/ethtool)
~ $

~ $ qlist nvidia-drivers | grep /lib/modules
/lib/modules/2.6.28-core2/video/nvidia.ko
~ $

HTH



-- 
Best regards,
Daniel