[gentoo-dev] Re: Segregating KDE?

[Duncan]

Anthony Gorecki posted <200409181103.01872.anthony@××××××××××.com>,
excerpted below,  on Sat, 18 Sep 2004 11:02:53 -0700:

> On Saturday 18 September 2004 2:16 am, Dan Armak wrote:
>> A kde configure script takes as much as a minute or more to run. Today when
>> you emerge all of kde you run ~17 configure scripts, i.e. as much as 20
>> minutes goes there (of course everything depends on the speed of the
>> machine). If all kde-base packages are split into separate subpackage
>> ebuilds, you'll get hundreds of subpackags (200+).
>
> Perhaps instead of using completely independent packages for the software
> applications, a set of "pseudo-packages" could be created to alleviate the
> extra configuration requirements?
>
> I've previously used the DO_NOT_COMPILE option for the KDE ebuilds and
> successfully screened out many of the unwanted packages. If the dependencies
> for any given software application were known (herein lies the large amount
> of maintenance), it should then be possible to manipulate that environment
> variable to only compile what is necessary for the user. Granted it would
> take a fair amount of script-work, however it's an option to consider.

As a Gentoo and KDE user that hopes to someday be a Gentoo developer..

I to have had a bit of experience with DO_NOT_COMPILE.  Namely, with the
KDE 3.3.0 beta ebuilds, on AMD64 (and often running ~amd64 keyword added
then removed toolchain elements, mainly binutils and glibc, so bug reports
might be "noise"), I had to use that to tell KPovModeler (IIRC) from
kdegraphics not to compile, as it was running into an error rather more
advanced than my ability to fix.

I have a suggestion based on the now ~* masked due to linux26-headers
requirement glibc-2.3.4-20040916 and its new method for handling locales. 
It has a new "userlocales" use flag, which when activated, only merges the
locales listed in /etc/locales.build.  Since I only use en-US and can't
read anything other than en anyway, that's a pretty neat way to cut
compile time for all those locales I don't need.  I like the idea!

I'd like to see it expanded, with perhaps several *.build files, maybe
moved out of /etc/ directly into /etc/portage/build or some such.  In each
case, the idea would be to allow user configuration of only parts of a
generally large package to be merged.  Another perfect example might be
xorg.  Create a /etc/portage/build/xorg.build file, which would have two
specifiers, graphics adaptor modules to be compiled, and input modules to
be compiled, so I could simply say ATI (or better yet Radeon) and
mouse/keyboard only.  (The make.conf VIDEO_CARDS= thing that I saw hinted
at in some post I read never seems to work, here, possibly because I don't
have it set quite right, as I've never come across anything listing
exactly what the options are and I probably have it wrong.  On the last
xorg merge I did I used ebuild and limited it by hand, and found it took
ati not radeon even tho they are separate drivers, and I have radeon in
the make.conf entry, so next time I'm going to try ati and see if it takes
that automatically.  It'd help if there was a comment in the ebuild
listing the choices...)

Of course, there'd be a kde.build file as well.  It would provide a
section for each kdexxx ebuild, and simply subtract anything not listed
from the build process by adding it to DO_NOT_COMPILE.

The idea here would be to control it in two ways.  First, as with glibc,
it'd only be enabled if the required use flag (disabled by default) was
on.  Otherwise, as glibc does with the locales, it would just build
all of them.  Second, the file would be put there by default, with all
sub-packages in it by default, so even if the use flag was enabled, unless
a user specifically commented out or deleted a subpackage from the list,
it would be compiled as it is now.  I'd suggest not even giving the option
of breaking kdelibs apart, and possibly keeping kdebase whole, as well,
simply to minimize the possibility of breaking anything else that depends
on them.

Then, at the top of the file put a big hairy warning about how some
package components, particularly in kdebase, are depended on by others,
and to disable the use flag and recompile all packages if there are
dependency issues, and then leave everything else up to the user.  Any
bugs on related dependency issues would be marked invalid, see the warning
in the file, etc. so it wouldn't become a big support issue.  Further, all
it would take for implementation would be a function added to kde-dist, to
parse kde.build, and add anything not listed in the appropriate ebuild
section to the DO_NOT_COMPILE env-var.   This function could then either
be invoked by the appropriate kde-dist function directly (thus requiring
no individual ebuild mods at all, keeping in mind that it defaults to
current build-all behavior so it could be added without changing current
behavior on current ebuilds except that another use flag would be there
now), or called by the specific ebuilds.

Alternatively, kde.build could list only the packages one did NOT want
merged, in each section.  That would probably be simpler to implement with
KDE, since all that would be required is to brainlessly put everything
listed directly in the env-var, but it might be preferable for all the
*.build files to operate the same, and since glibc's locale.build already
operates by inclusion of what's listed, that's the way I wrote it, above.

IMO, this idea fills all the customizability requirements, while at the
same time being quite simple to implement and support, because it doesn't
do any subpackaging with the subsequent dependency and maintenance issues.

The one disadvantage from a user perspective is that it would require
remerging the entire ebuild if another subpackage was desired, but given
the trade-offs, I see that as quite acceptable.  Users would either
compile and merge everything as they now do by default, or they'd be
excising subpackages as they so chose, with results no different than a
forced recompile if they changed their mind about use flags.

>From my perspective, this would be a perfect way to implement
configurability at a level beyond that which it is practical to do with
use flags, due to their incredible proliferation if one tries.  Obviously,
I really like the solution as I've seen it in glibc! =:^)

-- 
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