Removing X and anything Dependant on it from Gentoo

[seablade]

Hey Mikhail, or any other Gentoo users out there, and of yall know of a good way of removing a package and anything that is dependant on it? In this instance I am referring to X(As I seem to have developed many problems in my X install) and any WMs, programs, and whatnot dependant on it.

I am also considering siwtching to modular X, any advantages or disadvantages I should be aware of?

Seablade

[bsmith]

Maybe change your flags to a -X, -gtk etc and do a -newuse emerge world?

[seablade]

Its definitly an idea, the problem is I am not sure that that would get rid of the programs, more just update the ones directly and try to compile everytihng else for commandline.

But thanks for the idea.

Seablade

[c0bblers]

Hi there,

Been using Gentoo for yonks now so I might be able to help you out a bit. Reverse dependancies are still something of a weakness of portage. Anyways, removing X and anything that depends on it will remove a LOT of stuff but if you REALLY wanna do it :)....

First make sure you have the ultra useful gentoolkit package installed (emerge gentoolkit). Then type:

# equery depends xorg-x11

You'll might have to be a bit more specific than that though so something like "x11-base/xorg-x11" may be needed (can't test it 'cause I'm away from my Gentoo boxes).

This will generate a list of all the packages that depend on xorg. Get that to output to a file and then check that there's nothing silly in there, you could be surprised what depends on X.

# equery depends xorg-x11 > package_list

Will output to file. You might need use the nocolour option for equery or something to avoid weird character strings (again can't test it ATM).

Once you've checked the file listing you can then hand it off to emerge but you'll have to stick an = at the beginning of each package name (e.g. =media-sound/xmms-1.2.10-r9) or take out the version numbers. You can probably just edit the file and type

# emerge `cat package_list`

Hope this helps.

Cheers,
James

[seablade]

Well I already went ahead and reinstalled gentoo(Yea for seperate home partitions;) but that is useful advice none the less, thanks for the heads up.

Seablade

[cyt0plas]

I've always been fond of hard masking packages I don't want when I'm setting up the system. Keeps me from emerging things I don't want to.

In your case
echo "x11-base/xorg-x11" >> /etc/portage/package.mask

should get the job done.

[seablade]

Yes but what I was referring to wasnt not wanting them, I already had them installed but something had gotten screwy with dependencies and various things and I wanted to remove it and all of its dependencies and start again with their reinstall. So in this case I dont believe a hard mask would have done the trick.

Thanks for the advice anyways;) It is kinda a moot point now though as I have already rebuilt that system;)

Seablade

[bigtrouble77]

I would imagine that a reinstall would be best. I've actually gotten into the habit of backup up my gentoo systems early on with the 'Stage 4' script in the event I royaly screw things up. I also compile everything with gtk and gnome support so virtually everything on my system would break if I tried to remove X.

Sorry it doesn't help your current situation much.

[seablade]

Heh ok just so things are clear, this is a rather old thread;) This situation was remedied by me some time ago with a reinstall of the OS.

Seablade

[mmarkin]

Hey Seablade, sorry I missed your thread. As c0bblers suggested, equery comes in very useful. I would:

0) Make sure your world file is "clean". I.e. make sure that only things that you explicitly wanted to install are in there. I personally accumulated lots of cruft in the world file before I finally learned the proper ways of using Portage.
1) Make sure you unmerge everything that depends on X.
2) Unmerge X.
3) `emerge --pretend depclean`
4) Use equery to sanity check all apps depclean wants to remove.
5) Let depclean go if all is fine or selectively unmerge apps that you deem safe.

Step 0 is basically the key here. As any Portage guide will tell you, you should only emerge applications you want as an "end-result". I.e. if app A depends on lib B, don't emerge lib B as that would add it to the world file (and Portage will never see it as an unnecessary package when app A is unmerged). If you still need to do this (i.e. you need to re-emerge a library to fix linking), use the --oneshot parameter for emerge. This will tell emerge not to add the package to the world file.

Mikhail

[c0bblers]

Yeah that'd get rid of anything that X depended on but nothing else does. The problem is that anything that depends on X will still be around so the next time you run emerge update in deep mode (or normal mode in some instances) X will get reinstalled. Reverse dependancies are difficult to calculate and portage doesn't do them, hence the need for equery.

I echo the need to clean up your world file on occation, and also to NEVER use USE="blah" on the command line. If you use portage properly depcleans should work fine 90% of the time. It's always a good idea to run an "emerge -uDva --newuse world" before doing a depclean to make sure everything is up to speed with your USE flags and avoid removing things that you shouldn't.

[mmarkin]

Yeah that'd get rid of anything that X depended on but nothing else does. The problem is that anything that depends on X will still be around so the next time you run emerge update in deep mode (or normal mode in some instances) X will get reinstalled. Reverse dependancies are difficult to calculate and portage doesn't do them, hence the need for equery.

I am not sure what you mean. This is what I meant by "1) Make sure you unmerge everything that depends on X.":


~ # equery depends xorg-x11
[ Searching for packages depending on xorg-x11... ]
x11-drivers/ati-drivers-8.14.13-r3
x11-misc/xcompmgr-1.1
x11-misc/transset-0.1_pre20040821


Edit: I think I see what you meant now. Things like fluxbox didn't show up in the list above. Bummer.


I echo the need to clean up your world file on occation, and also to NEVER use USE="blah" on the command line. If you use portage properly depcleans should work fine 90% of the time. It's always a good idea to run an "emerge -uDva --newuse world" before doing a depclean to make sure everything is up to speed with your USE flags and avoid removing things that you shouldn't.

Precisely

[c0bblers]

Had a brainwave on why it didn't list fluxbox et. al on the list there, I don't think equery picked them up due to virtual packages. Because gentoo's been set up to allow the use of different incarnations of the X server all X servers provide a virtual package which other packages then depend on. Xcompmgr the ATI drivers etc. are all specific to xorg. SO, trying:

~ # equery depends virtual/x11

SHOULD pick up fluxbox etc. Hehe, should've checked the theory myself, my bad.

[seablade]

Ok I am a little curious why yall are so much against the USE="whatever" on the commandline. Personally I have done this on a couple of occasions, though most of the time I do try to get it in my /etc/portage/package.use file.

Seablade

[c0bblers]

Ok I am a little curious why yall are so much against the USE="whatever" on the commandline. Personally I have done this on a couple of occasions, though most of the time I do try to get it in my /etc/portage/package.use file.

Seablade
Because it totally screws up depcleans and makes the dependancy tree created by portage not tally with the current system....I'll try and explain. OK, say for example you install application foobar with something like

USE="gtk" emerge foobar

but in your make.conf you have USE="blah blah -gtk". Foobar pulls in the gtk+ package as a dependancy and so gtk+ is emerged along with foobar. If you then do an emerge depclean portage builds a dependency tree from your world file packages downwards. Since you have -gtk in your make.conf portage calculates that gtk+ is not in your dependency tree and so it's removed. You then go to use foobar and it fails to run 'cause it can't find gtk+....hope that makes sense.

[seablade]

Ahh ok, makes sense, thought the only things i have in my make.conf as removed(Aka -whatever) I dont put in the USE on the commandline, so I doubt it would make to much of a difference, though I suppose it could.

Seablade

[c0bblers]

Ahh ok, makes sense, thought the only things i have in my make.conf as removed(Aka -whatever) I dont put in the USE on the commandline, so I doubt it would make to much of a difference, though I suppose it could.

Seablade
A flag doesn't necessarily need to be specifically in the make.conf as -blah for it to be treated as such, flags are on or off by default, and if it's not specifically set anywhere the flag is effectively -blah.

[troymc]

I second everything c0bbler said. Setting USE flags on the command line can really hose your system up.

The proper way to set USE flags on a per package basis is in /etc/portage/package.use

For example, you probably should have this line in there:

sys-libs/glibc userlocales

That way the system knows that the 'userlocales' USE flag is enabled for that package - and depclean will know it too. Kinda off-topic but: This flag keeps your system from building *every* locale when building glibc, and is the equivalent of:

USE="userlocales" emerge glibc

Instead it only builds those you specify in /etc/locales.build


troymc

[mmarkin]

Had a brainwave on why it didn't list fluxbox et. al on the list there, I don't think equery picked them up due to virtual packages. Because gentoo's been set up to allow the use of different incarnations of the X server all X servers provide a virtual package which other packages then depend on. Xcompmgr the ATI drivers etc. are all specific to xorg. SO, trying:

~ # equery depends virtual/x11

SHOULD pick up fluxbox etc. Hehe, should've checked the theory myself, my bad.

You're absolutely correct. That indeed gives me a whole load of apps, which makes more sense. Care to provide a few links to info re: virtual packages? Learn something every day :)

Mikhail

[c0bblers]

Errr, I'll have a look around for some docs on it...I remember when they introduced the virtual package so that's how I know about it ;). But then when I started using Gentoo the emerge command had no unmerge support :D.

[troymc]

The current draft standard for virtuals is GLEP37 (http://www.gentoo.org/proj/en/glep/glep-0037.html)

This (http://dev.gentoo.org/~spb/metapkg-glep.txt) is also very informative.



troymc



Enjoying my new 9750! :banana:

Sager 9750-V | AMD A64 FX-60 | 17" WUXGA LCD | nVIDIA GeForce Go 7800 | 2048MB 400DDR | 2x 100GB 7200RPM SATA | 8x DVD+- combo drive with DVD+R DL | 802.11g wireless + Bluetooth | 3 Year Extension w/ Onsite

[mmarkin]

Thanks!