OK, I built a couple of Gentoo systems recently, one on a Mac clone,
and one on an old
X86 clone with a 700MHz Celeron (ick) .

On the Mac, I initially started out with Gnome, then decided that I
hated what Gnome
has become, and that I wanted to remove it and install kde. Up to this
point, emerge had
presented me with no difficulties.

Well, I immediately became confused when I tried to remove Gnome. I
had used
"emerge gnome" to install Gnome, so I figured "emerge clean gnome"
would do the trick
(I figured clean was better than unmerge since it would check
dependencies, according to the
manpage). Well, it declined to remove anything. OK, so I tried "emerge
unmerge gnome".
That didn't work either. So I took the listing that I had saved when I
had done
"emerge -p gnome" and tried running "emerge clean" on each package in
the list (but in
reverse order). I didn't get past the last item in the list. Finally,
I used "emerge unmerge"
on the list (in reverse order) and that worked.

What a pain! Why was I not able to use just specify the same thing
("gnome") in the uninstall
that I had specified in the install? And why did clean refuse to work?
When removing packages
I would like for it to protect me from removing something that
something else depends on.

I am confronted with a similar problem on the Celeron. Due to the
sparse information in
the /etc/make.conf, I had originally built the system all the way up
to and including kde
using march=pentium2, only to discover that I could have used
march=pentium3 (I have
a coppermine processor, and according to the information in the kernel
config you can
optimize for pentum3 if you have coppermine). So I fixed
/etc/make.conf, and proceeded to
rebuild the kernel. I immediately noticed a performance improvement.
So I grabbed the output
of "ls -lat /usr/bin" and used "qpkg -f" to figure out the packages
that had been built before
the change to /etc/make.conf, and rebuild them with "emerge
<packagename>" . That's done.
But now I would like to rebuild xfree86 and kde. It would be nice to
be able to say
"emerge xfree86" and "emerge kde" and have it rebuild it all. But it
won't once it realizes that
xfree86 and kde are already installed. I could use a listing from
"emerge -p" (before the
xfree86 and kde installs) as on the Mac, but I this time I don't have
it.

Is there some way to find out what "emerge kde" would install if kde
were not installed?

Griff

On Mon, 01 Dec 2003 20:14:19 -0800, Griff Miller wrote:

> Well, I immediately became confused when I tried to remove Gnome. I
> had used
> "emerge gnome" to install Gnome, so I figured "emerge clean gnome"
> would do the trick
> (I figured clean was better than unmerge since it would check
> dependencies, according to the
> manpage). Well, it declined to remove anything.

well it depends on your definition of 'functionality' ...
in the context of 'clean' it means it'll unmerge old packages
that portage thinks newer versions will take care of. looking
at the example in the manpage:
For example, emerge clean binutils cleans out old versions of binutils
it does _not_ unmerge binutils, it just cleans out the older versions


> OK, so I tried "emerge
> unmerge gnome".
> That didn't work either.

define 'didnt work' ... it 'worked' only because 'gnome' is a meta-package ...
that is, it doesnt actually install any real files ... it just depends on
all the components that make up 'gnome' ... the same goes for kde ...
there is no way in portage to currently unmerge gnome and all of its
dependencies ... after all, with the current state of portage, there is
no way to figure out what exactly to unmerge ...
for example, bringing gnome on a stage3 system pulls in GTK. if you later
emerge something like games-util/xqf or media-gfx/gimp, they need GTK. if
at a LATER stage you say 'i want to unmerge GNOME and all its DEPEND' ...
well, what do you unmerge ? i guess you wouldnt unmerge GTK anymore since
other things DEPEND on it, but like i said, portage doesnt currently have
that ability.
i.e. you have to do it by hand

> So I took the listing that I had saved when I
> had done
> "emerge -p gnome" and tried running "emerge clean" on each package in
> the list (but in
> reverse order). I didn't get past the last item in the list. Finally,
> I used "emerge unmerge"
> on the list (in reverse order) and that worked.

behavior you describe is correct (see above)

> What a pain! Why was I not able to use just specify the same thing
> ("gnome") in the uninstall
> that I had specified in the install? And why did clean refuse to work?
> When removing packages
> I would like for it to protect me from removing something that
> something else depends on.

see above

> I am confronted with a similar problem on the Celeron. Due to the
> sparse information in
> the /etc/make.conf, I had originally built the system all the way up
> to and including kde
> using march=pentium2, only to discover that I could have used
> march=pentium3 (I have
> a coppermine processor, and according to the information in the kernel
> config you can
> optimize for pentum3 if you have coppermine).

actually, saying 'i have a celeron' means you could build it with
pentium2, or pentium3, or even pentium4 ... it's up to the user to figure
that out for themselves and to choose the correct flag ...
we just fell back to the lcd (that is, pentium2)

> So I fixed
> /etc/make.conf, and proceeded to
> rebuild the kernel. I immediately noticed a performance improvement.
> So I grabbed the output
> of "ls -lat /usr/bin" and used "qpkg -f" to figure out the packages
> that had been built before
> the change to /etc/make.conf, and rebuild them with "emerge
> <packagename>" . That's done.
> But now I would like to rebuild xfree86 and kde. It would be nice to
> be able to say
> "emerge xfree86" and "emerge kde" and have it rebuild it all. But it
> won't once it realizes that
> xfree86 and kde are already installed. I could use a listing from
> "emerge -p" (before the
> xfree86 and kde installs) as on the Mac, but I this time I don't have
> it.

`emerge -e xfree86 kde`
the -e is for 'empty', review the manpage
you could also look at the CFLAGS file in /var/db/pkg/<category>/<pkg>/ to
see what packages were built with what CFLAGS

> Is there some way to find out what "emerge kde" would install if kde
> were not installed?

only way is to `emerge -e kde` and review the list yourself
-mike

Mike, thanks for replying.

Mike Frysinger <vapier@gentoo.org> wrote in message news:<pan.2003.12.02.04.53.13.763665@gentoo.org>.. .
> On Mon, 01 Dec 2003 20:14:19 -0800, Griff Miller wrote:
>
> > Well, I immediately became confused when I tried to remove Gnome. I
> > had used
> > "emerge gnome" to install Gnome, so I figured "emerge clean gnome"
> > would do the trick
> > (I figured clean was better than unmerge since it would check
> > dependencies, according to the
> > manpage). Well, it declined to remove anything.
>
> well it depends on your definition of 'functionality' ...
> in the context of 'clean' it means it'll unmerge old packages
> that portage thinks newer versions will take care of. looking
> at the example in the manpage:
> For example, emerge clean binutils cleans out old versions of binutils
> it does _not_ unmerge binutils, it just cleans out the older versions

So there isn't a command that will remove a package or packages, while
checking first for dependencies and throwing an error if there are
any? i.e. like
"rpm -e" or "pkgrm" would do?

> > OK, so I tried "emerge
> > unmerge gnome".
> > That didn't work either.
>
> define 'didnt work' ...

I mean it wasn't the reverse of "emerge gnome" . Nothing happened.

> it 'worked' only because 'gnome' is a meta-package ...
> that is, it doesnt actually install any real files ...

I had gathered that, or something to that effect (see below).

> it just depends on
> all the components that make up 'gnome' ... the same goes for kde ...
> there is no way in portage to currently unmerge gnome and all of its
> dependencies ... after all, with the current state of portage, there is
> no way to figure out what exactly to unmerge ...

Well, that makes it a little clearer. I had thought that "gnome" or
"kde" were
more like aliases for a list of packages, such that portage could get
that
list again later for whatever reason (like unmerge) .

Let's see, if "emerge kde" would also "inject" kde, and if there were
a way for unmerge
to check dependencies, then "emerge unmerge kde" would list those
dependencies in
an error message.

Just fantasizing.

> for example, bringing gnome on a stage3 system pulls in GTK. if you later
> emerge something like games-util/xqf or media-gfx/gimp, they need GTK. if
> at a LATER stage you say 'i want to unmerge GNOME and all its DEPEND' ...
> well, what do you unmerge ? i guess you wouldnt unmerge GTK anymore since
> other things DEPEND on it,

Right. emerge would throw an error.

> but like i said, portage doesnt currently have
> that ability.
> i.e. you have to do it by hand

So the upshot is that portage simply doesn't have the functionality I
presumed it would have, coming from the SYSV (with pkgrm) and
RPM (with rpm -e) worlds. OK, I just assumed it would have, and
was "in search of" .

> > I am confronted with a similar problem on the Celeron. Due to the
> > sparse information in
> > the /etc/make.conf, I had originally built the system all the way up
> > to and including kde
> > using march=pentium2, only to discover that I could have used
> > march=pentium3 (I have
> > a coppermine processor, and according to the information in the kernel
> > config you can
> > optimize for pentum3 if you have coppermine).
>
> actually, saying 'i have a celeron' means you could build it with
> pentium2, or pentium3, or even pentium4 ... it's up to the user to figure
> that out for themselves and to choose the correct flag ...
> we just fell back to the lcd (that is, pentium2)

I come from the SPARC and PowerPC world, and therefore know little of
the history of the Pentium chip. What I saw in /etc/make.conf was
this:

# CPU types supported in gcc-3.2 and higher: athlon-xp, athlon-mp,
# athlon-tbird, athlon, k6, k6-2, k6-3, i386, i486, i586 (Pentium),
i686
# (PentiumPro), pentium, pentium-mmx, pentiumpro, pentium2 (Celeron),
pentium3.
# Note that Gentoo Linux 1.4 and higher include at least gcc-3.2.

That led me to believe that all Celerons are pentium2 .

I don't mean to come across as complaining. I just thought it might be
nice
if a little more info was given. I almost gave up on Gentoo, because
it didn't
seem any faster than Mandrake which I had previously loaded. But I
discovered
my error in time not to make the mistake of pitching Gentoo out the
window.

> > So I fixed
> > /etc/make.conf, and proceeded to
> > rebuild the kernel. I immediately noticed a performance improvement.
> > So I grabbed the output
> > of "ls -lat /usr/bin" and used "qpkg -f" to figure out the packages
> > that had been built before
> > the change to /etc/make.conf, and rebuild them with "emerge
> > <packagename>" . That's done.
> > But now I would like to rebuild xfree86 and kde. It would be nice to
> > be able to say
> > "emerge xfree86" and "emerge kde" and have it rebuild it all. But it
> > won't once it realizes that
> > xfree86 and kde are already installed. I could use a listing from
> > "emerge -p" (before the
> > xfree86 and kde installs) as on the Mac, but I this time I don't have
> > it.
>
> `emerge -e xfree86 kde`
> the -e is for 'empty', review the manpage
> you could also look at the CFLAGS file in /var/db/pkg/<category>/<pkg>/ to
> see what packages were built with what CFLAGS

Yes, I later figured this out - thanks for the confirmation. If only
I'd
thought of the -e before I did all the manual rebuilding. :^} That
would have
been a one-stroke way of rebuilding everything. Oh, well. It's good
practice.
It's grinding away now .

Thanks for the help! I am much happier with Gentoo on my crummy
hardware
than other distros I've tried. Right now I'm trying to install on a
3rd machine,
a 366MHz Pentium2 laptop from Dell. There's something amiss in the
networking.
I get it booted from the basic CD via "gentoo dopcmcia" and ifconfig
shows that
eth0 (a PCMCIA card) is configured off of the DHCP server on my LAN,
but
when I try to use the connection (e.g. ping 1.2.3.4) I get odd
low-level messages and
the ping doesn't work. The laptop is across town at the moment -
perhaps tomorrow
I'll try again and post the actual messages.

Griff

So anyway, it was like, 05:26 CET Dec 05 2003, you know? Oh, and, yeah,
Griff Miller was all like, "Dude,
> Mike Frysinger <vapier@gentoo.org> wrote in message news:<pan.2003.12.02.04.53.13.763665@gentoo.org>.. .
>> On Mon, 01 Dec 2003 20:14:19 -0800, Griff Miller wrote:

>> > Well, I immediately became confused when I tried to remove Gnome.
>> > I had used "emerge gnome" to install Gnome, so I figured "emerge
>> > clean gnome" would do the trick (I figured clean was better than
>> > unmerge since it would check dependencies, according to the
>> > manpage). Well, it declined to remove anything.
>>
>> well it depends on your definition of 'functionality' ... in the
>> context of 'clean' it means it'll unmerge old packages that portage
>> thinks newer versions will take care of. looking at the example
>> in the manpage: For example, emerge clean binutils cleans out old
>> versions of binutils it does _not_ unmerge binutils, it just cleans
>> out the older versions
>
> So there isn't a command that will remove a package or packages,
> while checking first for dependencies and throwing an error if there
> are any? i.e. like "rpm -e" or "pkgrm" would do?

'emerge -C foo' or 'emerge unmerge foo'

'man emerge' or 'emerge --help' while you're at it.

Keep in mind that it won't warn you like 'rpm -e' will if you're about
to remove something that is depended upon, but getting back the stuff
that you actually do need is just an 'emerge -Duv world' away in that
case.

I'd suggest trying to keep /var/cache/edb/world as trimmed as
possible, for example not having libs there explicitly since the
depends will take care of that stuff for you.

Ie, if you manually re-emerge a lib that's already on your system,
you can (should) remove the line from the world file afterwards.

>> > OK, so I tried "emerge unmerge gnome". That didn't work either.
>>
>> define 'didnt work' ...
>
> I mean it wasn't the reverse of "emerge gnome" . Nothing happened.

The "gnome" package is there to get all the gnome stuff in one fell
swoop. To get rid of gnome completely, you might try

'emerge -C gnome && emerge depclean'

since after you've removed the "collective" gnome package, most of the
depends on the various gnome parts should be gone. There might still
be stuff that needs parts of gnome (or kde, similarly) tho, so don't
expect everything to go away completely unless you've really cleaned
out.

Less fearless individuals might do 'emerge depclean -p' first.

hth.

--
Time flies like an arrow, fruit flies like a banana. Perth ---> *
17:36:51 up 1 day, 15:42, 5 users, load average: 2.05, 2.06, 2.00
$ cat /dev/bollocks Registered Linux user #261729
reinvent sticky synergies