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

[Duncan]

Dan Armak posted <200410192040.54826.danarmak@g.o>, 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@g.o mailing list