[gentoo-dev] ANN: broken-up kde ebuilds (aka 'emerge kmail')

[gentoo-dev] ANN: broken-up kde ebuilds (aka 'emerge kmail')

[Dan Armak]

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

Hi all,

Perhaps the oldest request of Gentoo KDE is to have individual ebuilds for all 
KDE apps - konqueror, kmail etc. Most people will probably never use over 
half the stuff 'emerge kde' installs, and it's hardly Gentooish to force it 
on them.

I've spent the last few years pointing out to various people why this couldn't 
be done (well). Eventually I got really tired, so we did it.

So without further ado, I point you to http://kde-metaebuilds.berlios.de/ and 
the more detailed explanations there. Brought to you by Simone Gotti 
<motaboy@gentoo.org> and yours truly.

*** Current status: early beta. Works For Us (tm). DO NOT send bugreports to 
*.gentoo.org - join the mailing list at berlios.de. ***

---

For everyone who's still reading...

You probably remember me saying this wouldn't be done because an 'emerge 
kde-meta' would take a few hours longer than a classic 'emerge kde'. This is 
true. So I refer you to http://dev.gentoo.org/~danarmak/ where you'll find 
the experimental confcache patch to portage, which virtually eliminates the 
overhead of running configure for every tiny ebuild.

However, while the ebuilds are in early beta, confcache is in late alpha. A 
few known (non-dangerous) problems exist. So if you use it, be sure of what 
you're doing. I'd also like to ask anyone and everyone to help make confcache 
better...

I release when ready. And what this's ready for is a lot of testing, rather 
than a lot of production use :-) But there are no known issues (with the 
ebuilds), so please go ahead and use them.

Eventually, esp. if and when confcache goes stable and is added to portage, 
these ebuilds can make their way into portage also.

-- 
Dan Armak
Gentoo Linux developer (KDE)
Matan, Israel
Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key
Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD  0069 508D 9143 8D5F 8951

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] ANN: broken-up kde ebuilds (aka 'emerge kmail')

[Roman Gaufman]

err, DO_NOT_COMPILE="kmail" in /etc/make.conf does just that, and
supports every package or even service KDE has to offer. Feel free to
not compile ksmserver or kinit as well --  this will break things, but
the fact is, gentooists always had the possibility to do this!

What exactly do you propose here? -- do you actually propose gentoo
developers should split the metapackages into close to 100 ebuilds? --
what gain over DO_NOT_COMPILE does this give?

How about putting this in the ebuilds:
kmail? || DO_NOT_COMPILE="${DO_NOT_COMPILE} kmail"
konqueror? || DO_NOT_COMPILE="$DO_NOT_COMPILE} konqueror"
kdm? || DO_NOT_COMPILE="$DO_NOT_COMPILE kdm"
...

I'm not in favor of this as this will make many extra use flags, but
it still seems a far better solution than splitting the meta packages.

If only you checked out the forum ;) -- its a popular question as you
rightly said.

Roman


On Tue, 19 Oct 2004 19:26:13 +0200, Dan Armak <danarmak@gentoo.org> wrote:
> Hi all,
>
> Perhaps the oldest request of Gentoo KDE is to have individual ebuilds for all
> KDE apps - konqueror, kmail etc. Most people will probably never use over
> half the stuff 'emerge kde' installs, and it's hardly Gentooish to force it
> on them.
>
> I've spent the last few years pointing out to various people why this couldn't
> be done (well). Eventually I got really tired, so we did it.
>
> So without further ado, I point you to http://kde-metaebuilds.berlios.de/ and
> the more detailed explanations there. Brought to you by Simone Gotti
> <motaboy@gentoo.org> and yours truly.
>
> *** Current status: early beta. Works For Us (tm). DO NOT send bugreports to
> *.gentoo.org - join the mailing list at berlios.de. ***
>
> ---
>
> For everyone who's still reading...
>
> You probably remember me saying this wouldn't be done because an 'emerge
> kde-meta' would take a few hours longer than a classic 'emerge kde'. This is
> true. So I refer you to http://dev.gentoo.org/~danarmak/ where you'll find
> the experimental confcache patch to portage, which virtually eliminates the
> overhead of running configure for every tiny ebuild.
>
> However, while the ebuilds are in early beta, confcache is in late alpha. A
> few known (non-dangerous) problems exist. So if you use it, be sure of what
> you're doing. I'd also like to ask anyone and everyone to help make confcache
> better...
>
> I release when ready. And what this's ready for is a lot of testing, rather
> than a lot of production use :-) But there are no known issues (with the
> ebuilds), so please go ahead and use them.
>
> Eventually, esp. if and when confcache goes stable and is added to portage,
> these ebuilds can make their way into portage also.
>
> --
> Dan Armak
> Gentoo Linux developer (KDE)
> Matan, Israel
> Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key
> Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD  0069 508D 9143 8D5F 8951
>
>
>

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] ANN: broken-up kde ebuilds (aka 'emerge kmail')

[Dan Armak]

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

On Tuesday 19 October 2004 20:23, Roman Gaufman wrote:
> err, DO_NOT_COMPILE="kmail" in /etc/make.conf does just that, and
> supports every package or even service KDE has to offer. Feel free to
> not compile ksmserver or kinit as well --  this will break things, but
> the fact is, gentooists always had the possibility to do this!
>
> What exactly do you propose here? -- do you actually propose gentoo
> developers should split the metapackages into close to 100 ebuilds? --

I'm not proposing anything. I'm announcing the fact that I and another Gentoo 
developer (motaboy) have actually split the monolithic ebuilds into well over 
300 new packages.

> what gain over DO_NOT_COMPILE does this give?

It allows portage to manage interdependencies and, in fact, everything else it 
manages. Heavy use of DO_NOT_COMPILE, such as emerging only kmail + its deps 
from all of kdepim (of course each user has to figure out for himself what 
those deps are, first), is more or less equivalent to linux from scratch. 
It'd be manual building, except portage will think it knows what is 
installed, and will be wrong.

-- 
Dan Armak
Gentoo Linux developer (KDE)
Matan, Israel
Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key
Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD  0069 508D 9143 8D5F 8951

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] ANN: broken-up kde ebuilds (aka 'emerge kmail')

[Chris L. Mason]

On Tue, 19 Oct 2004 19:26:13 +0200, Dan Armak <danarmak@gentoo.org> wrote:
> Hi all,
> 
> Perhaps the oldest request of Gentoo KDE is to have individual ebuilds for all
> KDE apps - konqueror, kmail etc. Most people will probably never use over
> half the stuff 'emerge kde' installs, and it's hardly Gentooish to force it
> on them.
> 
> I've spent the last few years pointing out to various people why this couldn't
> be done (well). Eventually I got really tired, so we did it.
> 
> So without further ado, I point you to http://kde-metaebuilds.berlios.de/ and
> the more detailed explanations there. Brought to you by Simone Gotti
> <motaboy@gentoo.org> and yours truly.
> 

Awesome, great job!  I'll definitely be using this once I get Linux
working on my iMac G5. I hope you manage to get it into portage.

Thanks,


Chris

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] ANN: broken-up kde ebuilds (aka 'emerge kmail')

[Roman Gaufman]

On Tue, 19 Oct 2004 20:40:54 +0200, Dan Armak <danarmak@gentoo.org> wrote:
> > what gain over DO_NOT_COMPILE does this give?
> 
> It allows portage to manage interdependencies and, in fact, everything else it
> manages. Heavy use of DO_NOT_COMPILE, such as emerging only kmail + its deps
> from all of kdepim (of course each user has to figure out for himself what
> those deps are, first), is more or less equivalent to linux from scratch.
> It'd be manual building, except portage will think it knows what is
> installed, and will be wrong.
> 

over 300 ebuilds more to manage because of a slight gain in user
friendliness (not even usability)? -- sounds like one of ciaranm's
satires :)

What about USE="kde-minimal kmail" emerge kdepim? and now that you
mention dependencies. What about a package that depends on apache
having gdbm or ipv6 or threads support?

First of all, there is "etcat uses" and if its not convenient enough,
so what if things will fail with a clear message like kmail missing?
-- not any different than it is now :)

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] ANN: broken-up kde ebuilds (aka 'emerge kmail')

[Jason Rhinelander]

Roman Gaufman wrote:
> err, DO_NOT_COMPILE="kmail" in /etc/make.conf does just that, and
> supports every package or even service KDE has to offer. Feel free to
> not compile ksmserver or kinit as well --  this will break things, but
> the fact is, gentooists always had the possibility to do this!

Can you explain to me how this obviously wonderful feature would help me 
install *just* konqueror?  Would I need to add DO_NOT_COMPILE with a 
list as long as my arm to exclude everything in kde except for 
konqueror?  Perhaps someone could write a script to manage my 
DO_NOT_COMPILE variable as more applications are included in KDE and 
need to be excluded.

You've missed the entire point of the feature - it isn't about being 
able to remove certain parts of kde, it's about being able to install 
only selective parts of KDE.

> What exactly do you propose here? -- do you actually propose gentoo
> developers should split the metapackages into close to 100 ebuilds? --
> what gain over DO_NOT_COMPILE does this give?

It allows you to say "I want konqueror" instead of "I want kde without a 
list of packages as long as my arm that includes everything in kde 
except konqueror."

> How about putting this in the ebuilds:
> kmail? || DO_NOT_COMPILE="${DO_NOT_COMPILE} kmail"
> konqueror? || DO_NOT_COMPILE="$DO_NOT_COMPILE} konqueror"
> kdm? || DO_NOT_COMPILE="$DO_NOT_COMPILE kdm"
> ...
> 
> I'm not in favor of this as this will make many extra use flags, but
> it still seems a far better solution than splitting the meta packages.

How so?  DO_NOT_COMPILE is a rather dirty hack that this does a lot to 
alleviate.

> its a popular question as you rightly said.

DO_NOT_COMPILE only addresses the "I want kde, but I don't want 
konqueror" question, it does very little to address the "I want 
konqueror, but I don't want kde" question.  This does.

-- Jason Rhinelander
-- Gossamer Threads, Inc.

--
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: ANN: broken-up kde ebuilds (aka 'emerge kmail')

[Duncan]

Dan Armak posted <200410192040.54826.danarmak@gentoo.org>, excerpted
below,  on Tue, 19 Oct 2004 20:40:54 +0200:

> On Tuesday 19 October 2004 20:23, Roman Gaufman wrote:
>> err, DO_NOT_COMPILE="kmail" in /etc/make.conf does just that, and
>> supports every package or even service KDE has to offer. Feel free to
>> not compile ksmserver or kinit as well --  this will break things, but
>> the fact is, gentooists always had the possibility to do this!
>>
>> What exactly do you propose here? -- do you actually propose gentoo
>> developers should split the metapackages into close to 100 ebuilds? --
> 
> I'm not proposing anything. I'm announcing the fact that I and another
> Gentoo developer (motaboy) have actually split the monolithic ebuilds
> into well over 300 new packages.

Wow!

>> what gain over DO_NOT_COMPILE does this give?
> 
> It allows portage to manage interdependencies and, in fact, everything
> else it manages. Heavy use of DO_NOT_COMPILE, such as emerging only
> kmail + its deps from all of kdepim (of course each user has to figure
> out for himself what those deps are, first), is more or less equivalent
> to linux from scratch. It'd be manual building, except portage will
> think it knows what is installed, and will be wrong.

Interestingly, I just bit the bullet with 3.3.1 and configured all those
DO_NOT_COMPILEs for myself.  Some packages (kdebase, kdegames) I emerged
intact, others (kdeadmin, kdepim) I killed more than half the package.
kdepim was the worst to try to handle, as I had to backtrack on a couple
items (libical and libkcal) and compile them anyway due to dependency
issues. KMail and KNode were the main apps I wanted out of it, plus stuff
like the kfile metadata helpers.  kdeartwork I just killed the
screensavers.  A couple packages (kdeedu) I don't install at all anyway.

I had originally tried to use KDE_REMOVE_DIR from the ebuilds, but found
some stuff that didn't need actually compiled but DID need the dirs still
there for headers, etc.  (kpilot was one of these, altho it wasn't
compiled anyway due to use flag.)  I went back to DO_NOT_COMPILE.

Good point re portage tracking.  How do you manage the dependencies?  Do
you rebuild every time in-builddir, or do you look in the deployed system
first and only build in-builddir if it isn't yet deployed?  Is there a
list of an optimal emerge order if the latter?

I've been thinking about confcache.  I haven't tried using it yet, but I'm
certainly thinking about it.  Does it just do the main stuff, or does it
handle the entire configure step?  From earlier, I remember you (?) saying
what it DID cache, it invalidated entirely if there was just one change. I
can see how this would be simpler to implement.  However, if you are
caching everything, I'd hope you are doing it in segments, so that for
instance the normal C compile checks on endianness and bitlength and the
like, the "main" checks, are  not invalidated when something like qt
changes.  Perhaps section it into "main system qualities" like endianness
and the like that aren't likely to change, "standard bintools"
checks,"gcc", "kde/qt", "gtk/gnome", and "misc" (off the top of my head)?
That would maintain a grouping, but wouldn't invalidate the entire
confcache for one change to the kde dependencies with the 300 kde packages
you mention.  As I said, however, I haven't yet used it, just been turning
the idea over in my head, so...

-- 
Duncan - List replies preferred.   No HTML msgs.
"They that can give up essential liberty to obtain a little
temporary safety, deserve neither liberty nor safety." --
Benjamin Franklin



--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: ANN: broken-up kde ebuilds (aka 'emerge kmail')

[Dan Armak]

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

On Tuesday 19 October 2004 21:33, Duncan wrote:
> Good point re portage tracking.  How do you manage the dependencies?  Do
> you rebuild every time in-builddir, or do you look in the deployed system
> first and only build in-builddir if it isn't yet deployed?  

Very little rebuilding takes place.  Sometimes we copy built pieces from the 
live filesystem into the workdir, but in those cases we depend on having been 
build and installed first.

The only things that are rebuilt are the ones that have to be: static libs 
that are never installed. They are very few and this is negligible in terms 
of performance.

If you want the details, read the comments in kde-meta.eclass, then grep the 
ebuilds to get usage statistics of each mode of operation.

> Is there a 
> list of an optimal emerge order if the latter?
Not needed. Just normal portage deps.

> From earlier, I remember you (?) saying 
> what it DID cache, it invalidated entirely if there was just one change. I
> can see how this would be simpler to implement.  However, if you are
> caching everything, I'd hope you are doing it in segments

Caching is a builtin feature of configure scripts generated by autoconf. 
configure --help | grep cache will show you. All we do in confcache is store 
the cache after every run and give it to the next run.

So we have to invalidate it entirely and we can't segment it. Either behaviour 
would require basically replacing/rewriting autoconf. And if someone did do 
that, I'd be very happy :-) (Maybe the unsermake people?) But for now, this 
is all we can do.

That said if the existing bugs are worked out (like not panicking 
when /proc/cpuinfo's checksum changes due to cpu clock changes) our confcache 
is pretty good too in terms of performance.

-- 
Dan Armak
Gentoo Linux developer (KDE)
Matan, Israel
Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key
Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD  0069 508D 9143 8D5F 8951

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] ANN: broken-up kde ebuilds (aka 'emerge kmail')

[Anthony Gorecki]

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

On Tuesday 19 October 2004 10:26 am, Dan Armak wrote:
> I've spent the last few years pointing out to various people why this
> couldn't be done (well). Eventually I got really tired, so we did it.

This announcement is good to hear, though my one concern is regarding updates 
to KDE. Will only two developers be able to keep all of these packages 
up-to-date?


-- 
Anthony Gorecki
Ectro-Linux Foundation


[-- Attachment #2: Type: application/pgp-signature, Size: 828 bytes --]

Re: [gentoo-dev] ANN: broken-up kde ebuilds (aka 'emerge kmail')

[Anthony Gorecki]

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

On Tuesday 19 October 2004 2:30 pm, Anthony Gorecki wrote:
> This announcement is good to hear, though my one concern is regarding
> updates to KDE. Will only two developers be able to keep all of these
> packages up-to-date?

In addition, why aren't these segregated ebuilds blocking the official Gentoo 
KDE packages? I somehow doubt there will be much cooperation between the two 
sets of packages once they start clobbering each others' files.


-- 
Anthony Gorecki
Ectro-Linux Foundation


[-- Attachment #2: Type: application/pgp-signature, Size: 828 bytes --]

[gentoo-dev] Re: Re: ANN: broken-up kde ebuilds (aka 'emerge kmail')

[Duncan]

Dan Armak posted <200410192203.49686.danarmak@gentoo.org>, excerpted
below,  on Tue, 19 Oct 2004 22:03:41 +0200:

>> From earlier, I remember you (?) saying what it DID cache, it
>> invalidated entirely if there was just one change. I can see how this
>> would be simpler to implement.  However, if you are caching everything,
>> I'd hope you are doing it in segments
> 
> Caching is a builtin feature of configure scripts generated by autoconf.
> configure --help | grep cache will show you. All we do in confcache is
> store the cache after every run and give it to the next run.

Ahh...  I'd seen occasional (cached) entries in the various "checking ..."
messages.  This now makes sense.

> So we have to invalidate it entirely and we can't segment it. Either
> behaviour would require basically replacing/rewriting autoconf. And if
> someone did do that, I'd be very happy :-) (Maybe the unsermake people?)
> But for now, this is all we can do.

Aye... that /does/ sound like an unsermake project.

> That said if the existing bugs are worked out (like not panicking when
> /proc/cpuinfo's checksum changes due to cpu clock changes) our confcache
> is pretty good too in terms of performance.

Ugly!  Is the cache kept in such a way that for specific things like this,
one can go in and excise them using sed and the like?  That would seem the
best solution if so.  Simply make it as if the cpuinfo stuff hadn't been
cached, yet, so it'd test for it each time new.

Or.. perhaps even better, intercept the call for the cpuinfo checksum and
return the existing checksum, or the existing data, whichever is easier,
so it doesn't see it as changed.  Of course there'd have to be a way to
manually trigger a real check, say, if the CPU was replaced or whatever.

In another discussion, on the AMD64 list, we were talking about how
ultimately, power management for multiple CPUs might be accomplished by
using the developing CPU hotplug code to turn off one CPU at a time until
only one was left, then speed throttling the one CPU.  (I've seen kernel
discussion on using the hotplug code for suspend, tho not specifically
for power management not suspend, however, it's a logical extension, if
they are already talking about extending it to suspend, to use it for
throttling as well, given that existing throttling power management
doesn't work at all with multiple CPUs.)  If speed throttling throws a
wrench in the current system, consider what hotplugging CPUs will do to it
as well! <g> Perhaps whatever solution is found for the first can address
the second, when the time comes too, if it's planned for in advance.

-- 
Duncan - List replies preferred.   No HTML msgs.
"They that can give up essential liberty to obtain a little
temporary safety, deserve neither liberty nor safety." --
Benjamin Franklin



--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] ANN: broken-up kde ebuilds (aka 'emerge kmail')

[Simone Gotti]

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

On Tuesday 19 October 2004 21:30, Anthony Gorecki wrote:
> On Tuesday 19 October 2004 10:26 am, Dan Armak wrote:
> > I've spent the last few years pointing out to various people why this
> > couldn't be done (well). Eventually I got really tired, so we did it.
>
> This announcement is good to hear, though my one concern is regarding
> updates to KDE. Will only two developers be able to keep all of these
> packages up-to-date?

By now, we are in 4 developers (I'm the newest one). 
Yep the update will be more difficult, but I think that it won't take that 
more time. For example with a little script I've updated every ebuild from 
3.3.0 to 3.3.1 in 10 minutes. And I just tested all of them in one day of 
compilation, fixing some bugs. 
Probably using "repoman commit" this will take a little more time, and I'm 
thinking if this can be automated for example passing to it in the command 
line also the CVS changelog. (I'm just supposing, I don't know nothing of how 
repoman internally works). So I think that a good and easy solution can be 
found. 
Also remember that before a major version usually we're always testing kde CVS 
and also the various alpha, beta and rc1, these last versions are already in 
feature freeze and so the dependencies shouldn't change and the time to test 
the ebuilds is quite long (at least one month)

Bye!

[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]

Re: [gentoo-dev] ANN: broken-up kde ebuilds (aka 'emerge kmail')

[Simone Gotti]

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

On Tuesday 19 October 2004 21:56, Anthony Gorecki wrote:
> On Tuesday 19 October 2004 2:30 pm, Anthony Gorecki wrote:
> > This announcement is good to hear, though my one concern is regarding
> > updates to KDE. Will only two developers be able to keep all of these
> > packages up-to-date?
>
> In addition, why aren't these segregated ebuilds blocking the official
> Gentoo KDE packages? I somehow doubt there will be much cooperation between
> the two sets of packages once they start clobbering each others' files.

Because we hadn't already added the blocking DEPEND in the kde-meta.eclass. I 
think it's quite easy to implement.
I think that in these beta stage there are more important things before, and 
for testing we needed to keep also the official installed, so after 
installing all the splitted ones, we checked that removing the official 
doesn't left out any file.
But I have also to admit that the real testing should be done with the 
official kde uninstalled (I've already did it on x86 and a my friend on a 
sparc) also if I haven't found any difference (except for some headers in 
koffice-libs).  

Bye!

[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]

Re: [gentoo-dev] Re: Re: ANN: broken-up kde ebuilds (aka 'emerge kmail')

[Dan Armak]

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

On Wednesday 20 October 2004 00:42, Duncan wrote:
> Ugly!  Is the cache kept in such a way that for specific things like this,
> one can go in and excise them using sed and the like?  That would seem the
> best solution if so.  Simply make it as if the cpuinfo stuff hadn't been
> cached, yet, so it'd test for it each time new.

Yes. Just run it once and look in /var/cache/confcache... We keep the 
configure cache file as-is and another text file with file->checksum 
mappings, and a third file with env variable values (if eg $CC changes, the 
cache is dumped).

-- 
Dan Armak
Gentoo Linux developer (KDE)
Matan, Israel
Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key
Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD  0069 508D 9143 8D5F 8951

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Re: ANN: broken-up kde ebuilds (aka 'emerge kmail')

[Duncan]

Dan Armak posted <200410200638.28878.danarmak@gentoo.org>, excerpted
below,  on Wed, 20 Oct 2004 06:38:21 +0200:

> On Wednesday 20 October 2004 00:42, Duncan wrote:
>> Ugly!  Is the cache kept in such a way that for specific things like this,
>> one can go in and excise them using sed and the like? 
> 
> Yes. Just run it once and look in /var/cache/confcache... We keep the 
> configure cache file as-is and another text file with file->checksum 
> mappings, and a third file with env variable values (if eg $CC changes, the 
> cache is dumped).

Thanks.  Whatever else it may be (and it definitely has it's strong
points), Gentoo is certainly a continuing learning experience!  It's neat
to see how these things work, and even neater in contrast with the UNFREE
World of software in which I was up to a couple years ago.  It STILL
amazes me how all this not only code but development is conducted out in
the open where just anyone can examine and learn from it, hopefully
eventually contributing themselves.  Going back now is as unthinkable as
asking the defector whether he'd go back, until the old rule falls, anyway.

-- 
Duncan - List replies preferred.   No HTML msgs.
"They that can give up essential liberty to obtain a little
temporary safety, deserve neither liberty nor safety." --
Benjamin Franklin



--
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: ANN: broken-up kde ebuilds (aka 'emerge kmail')

[Sebastian Bergmann]

Roman Gaufman wrote:
> over 300 ebuilds more to manage because of a slight gain in user
> friendliness (not even usability)? -- sounds like one of ciaranm's
> satires :)

 To me it sounds like I do not have to emerge kdelibs and kdesdk in the
 future just because I want to use kcachegrind as a non-KDE user.

-- 
Sebastian Bergmann                      http://www.sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69


--
gentoo-dev@gentoo.org mailing list