[gentoo-dev] Reorganizing handling of target specific profiles (Was: Split desktop profile patches & news item for review)

[Mart Raudsepp <leio@gentoo.org>]

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

Hello,

On Thu, 2010-03-04 at 16:52 +0200, Theo Chatzimichos wrote:
> Hello
> I have managed to split the desktop profile to gnome and kde submenus. The 
> result can be found in kde-crazy overlay (not in layman) [1]

I think this whole approach of adding yet more subprofiles is highly
suboptimal. You are wanting to add at least 28 more subprofiles (the
number would reach the 80s if including hardened/mips, etc), whereas we
just had a sort-of discussion on how we have too many of them already at
http://archives.gentoo.org/gentoo-dev/msg_be393426980d12f341cabccfe5ab10aa.xml

Instead I think we should be improving "eselect profile" to support
multiple inheriting /etc/make.profile files in a user friendly fashion,
and in the end removing 249 subprofiles, instead of adding 28+.

Also, even after doing the addition of kde/gnome subprofiles, users
would like a better eselect profile for multi-inheriting, if they use
both GNOME and KDE on the same system (using both once in a while, or
multiple users on the same machine), as gnome/kde specific USE flags
would be only in their separate subprofiles then, and you want both.

So what I believe should be done instead of adding yet more subprofiles
is improving eselect profile to have good support for
multi-inheriting /etc/make.profile
With at least portage, one can have /etc/make.profile/ be a directory,
which is basically a user created profile in its own right, whereas with
the symlink to profile directory method, the toplevel profile used is
simply one in $PORTDIR/profiles/. Through that one can do a
multi-inheriting profile, so you could have a "parent" file in there,
with the following contents:

/usr/portage/profiles/default/linux/amd64/10.0
/usr/portage/profiles/targets/desktop

And you would effectively have the same as a symlink pointing
to /usr/portage/profiles/default/linux/amd64/10.0/desktop

Now as targets/ don't really do anything more than add USE flags to the
global set or package.use, we could support adding targets to the basic
release set for an arch with "eselect profile", so one could add both a
future gnome and a kde target, if desired. Or even also server flags as
well, if so desired by the user. And that without having to have all
those subprofiles per-arch/per-release profiles.

Once users are converted over to that method, there's no need for all
the target specific subprofiles we currently have. This at the last
count was 249 subprofiles for all the per-arch desktop/, server/ and
developer/ subprofiles, and we could remove them all, or simply phase
out when the 10.0 release phases out, replaced with a new release that
doesn't have the desktop/server/developer subprofiles in the first place
- giving a good migration and phase-out point.


So the steps for implementing this would be something like the
following:


* Improve eselect profile to have user friendly support for
multi-inheriting /etc/make.profile/, possibly special casing targets/ as
an add-on option/flag sort of thing.

* Test and stabilize the eselect-profile with those features

* Introduce the new gnome/kde targets and reorganize things. I would
suggest a new directory for this, that can have the options that
eselect-profile allows to add-on easily. For example basic-desktop,
gnome, kde, gentoo-developer, server, and so on - internally we can
inherit things as desired in there as an implementation detail (gnome
and kde can inherit from basic-desktop). Even adding lxde and xfce
targets is fine and simple, they can just inherit basic-desktop and
users don't need to find out that to get a target suitable for xfce,
they would have to go with the broad "desktop" or "basic-desktop"
target.
If "targets" is the best directory name for it, then that's fine too.
The current ones can be moved away to somewhere else, atomically with
tweaking all the inherits from default/ and hardened/ profiles at the
same time.

* Possibly have a new release set, that has no subprofiles from the
start, and can be accompanied with all the news and awareness raising it
takes to get users use this new method.

* All the things I forgot about.

* Eventually phase out completely the previous exponentially
increasing  subprofiles mess.

3) Profit.


Obviously I doubt to have time to work on it personally. I hope the guys
pushing for adding even more subprofiles can pick up this idea and
implement it, if discussion gives consensus this is a good way forward.



-- 
Mart Raudsepp
Gentoo Developer
Mail: leio@gentoo.org
Weblog: http://blogs.gentoo.org/leio

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]