[gentoo-dev] Split desktop profile patches & news item for review

[gentoo-dev] Split desktop profile patches & news item for review

[Theo Chatzimichos]

[-- Attachment #1: Type: Text/Plain, Size: 1317 bytes --]

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 splitted every desktop/ folder i found. The following issues raised though:
1) I didn't touch the hardened and selinux directories although they do 
contain a desktop folder. Should I proceed in those or not?
2) Some mips/ subdirs don't point to targets/, so I guess the split went to 
/dev/null. So I asked ssuominen who suggested to skip the mips directories, 
and I reverted. (Edit: ssuominen just committed changes in mips profiles in 
tree).
3) There were no desktop dirs for bsd/prefix etc.
4) Also take a look at how I splitted the USE flags (with ssuominen's and 
yngwin's suggestions) and propose your corrections plz. For example, I don't 
really like the firefox flag in kde, and I'd suggest a -firefox (ugly, I know) in 
kde's make.defaults

Please Please Please Please Please TEST / REVIEW (especially the arch teams 
plz)

I'll give three days max for the suggestions here etc, and then I'll proceed 
in creating the news item. So I guess it will be committed in a week max. 
Thanks

[1] http://git.overlays.gentoo.org/gitweb/?p=proj/kde-crazy.git;a=summary
-- 
Theo Chatzimichos (tampakrap)
Gentoo KDE/Qt Teams
blog.tampakrap.gr

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

Re: [gentoo-dev] Split desktop profile patches & news item for review

[Jeremy Olexa]

On Thu, 4 Mar 2010 16:52:50 +0200, Theo Chatzimichos
<tampakrap@gentoo.org>
wrote:
<snip>
> The following issues raised though:
<snip>
> 3) There were no desktop dirs for bsd/prefix etc.

That is not an issue for any prefix profiles. It is this way on purpose.

Thanks,
Jeremy

[gentoo-dev] Re: Split desktop profile patches & news item for review

[Duncan]

Theo Chatzimichos posted on Thu, 04 Mar 2010 16:52:50 +0200 as excerpted:

> For example, I don't really like the
> firefox flag in kde, and I'd suggest a -firefox (ugly, I know) in kde's
> make.defaults

That's not particularly practical, unfortunately.  konqueror seems to be 
dropping behind, doesn't have proper ssl/certificate management support 
with 4.x, and in general is getting less and less useful as a general 
purpose browser, and there's simply no way to keep up with the community 
development power of its extensions even if kde wanted to.  Pretty much 
everyone (including kde devs, based on remarks on the kde lists and 
planet) seems to use firefox for at least some of their browsing these 
days.

Someday, the webkit based rekonq is likely to take over from konqueror, 
but upstream says it's not yet mature enough for that.  Others use chrome 
or chromium, or icecat, or something else.  But firefox really does tend 
to be the cross-DE default, at least to the point that I believe that 
defaulting to USE=-firefox in the kde profiles would be a mistake.  Some 
of us would like nothing better than to be able to remove both it and with 
it gtk, but reality is, that's not going to be a useful default for some 
time, and given that, IMO, full optional but default-on support for it in 
the KDE desktop profiles via USE flags should be maintained.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Split desktop profile patches & news item for review

[Sebastian Pipping]

On 03/04/10 15:52, Theo Chatzimichos wrote:
> Hello
> I have managed to split the desktop profile to gnome and kde submenus.

How about XFCE (and LXDE)?


> The 
> result can be found in kde-crazy overlay (not in layman) [1]

If this is ever going to be used as a real overlay please set repo_name
to something other than "gentoo", e.g. "kde-crazy".


> I'll give three days max for the suggestions here etc, and then I'll proceed 
> in creating the news item. So I guess it will be committed in a week max. 

Out of curiosity: why the hurry?



Sebastian

Re: [gentoo-dev] Split desktop profile patches & news item for review

[Samuli Suominen]

On 03/04/2010 07:59 PM, Sebastian Pipping wrote:
> On 03/04/10 15:52, Theo Chatzimichos wrote:
>> Hello
>> I have managed to split the desktop profile to gnome and kde submenus.
> 
> How about XFCE (and LXDE)?

Pointless.

We (xfce) are fine with plain desktop/ profile (now, and after the gnome
and kde flags are stripped out of it).
The required flags are somewhat jpeg, png, dbus, cairo, gtk and that's
about it. HAL is optional.

I guess it's pretty much same for LXDE.

Re: [gentoo-dev] Split desktop profile patches & news item for review

[Ben de Groot]

On 4 March 2010 19:15, Samuli Suominen <ssuominen@gentoo.org> wrote:
> On 03/04/2010 07:59 PM, Sebastian Pipping wrote:
>> On 03/04/10 15:52, Theo Chatzimichos wrote:
>>> Hello
>>> I have managed to split the desktop profile to gnome and kde submenus.
>>
>> How about XFCE (and LXDE)?
>
> Pointless.
>
> We (xfce) are fine with plain desktop/ profile (now, and after the gnome
> and kde flags are stripped out of it).
> The required flags are somewhat jpeg, png, dbus, cairo, gtk and that's
> about it. HAL is optional.
>
> I guess it's pretty much same for LXDE.

As LXDE lead, I am very much for a "lighter" default desktop profile
without gnome and kde specific stuff enabled (as they are going to be
in their own subprofiles). There is no need for a separate profile for
LXDE, just a base desktop profile without too much bloat.

Cheers,
-- 
Ben de Groot
Gentoo Linux developer (qt, media, lxde, desktop-misc)
______________________________________________________

Re: [gentoo-dev] Split desktop profile patches & news item for review

[Joshua Saddler]

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

On Thu, 4 Mar 2010 16:52:50 +0200
Theo Chatzimichos <tampakrap@gentoo.org> wrote:

> I'll give three days max for the suggestions here etc, and then I'll proceed 
> in creating the news item. So I guess it will be committed in a week max. 
> Thanks

Feel free to submit some documentation patches now that all our docs are #$!@ed.
Thanks.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Split desktop profile patches & news item for review

[Ben de Groot]

On 5 March 2010 09:28, Joshua Saddler <nightmorph@gentoo.org> wrote:
> Feel free to submit some documentation patches now that all our docs are #$!@ed.
> Thanks.

No need for the drama, my friend. A couple of more choices in
profiles does not fuck up all our docs. Some clarification will need
to be added to docs that refer to the desktop profile, yes. That's
a good point. Let's start identifying which docs need updating.

Cheers,
-- 
Ben de Groot
Gentoo Linux developer (qt, media, lxde, desktop-misc)
______________________________________________________

Re: [gentoo-dev] Split desktop profile patches & news item for review

[Theo Chatzimichos]

[-- Attachment #1: Type: Text/Plain, Size: 828 bytes --]

On Friday 05 March 2010 14:57:32 Ben de Groot wrote:
> On 5 March 2010 09:28, Joshua Saddler <nightmorph@gentoo.org> wrote:
> > Feel free to submit some documentation patches now that all our docs are
> > #$!@ed. Thanks.
> 
> No need for the drama, my friend. A couple of more choices in
> profiles does not fuck up all our docs. Some clarification will need
> to be added to docs that refer to the desktop profile, yes. That's
> a good point. Let's start identifying which docs need updating.
> 
> Cheers,

I maintain the KDE docs, so I'll update them. I'll also send a doc patch for 
the gnome and xorg docs. I already blogged about it, and will write the news 
item. I suppose those are more than enough. Thanks for pointing that out
-- 
Theo Chatzimichos (tampakrap)
Gentoo KDE/Qt Teams
blog.tampakrap.gr

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

Re: [gentoo-dev] Split desktop profile patches & news item for review

[Zeerak Mustafa Waseem]

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

On Fri, Mar 05, 2010 at 03:46:50PM +0200, Theo Chatzimichos wrote:
> On Friday 05 March 2010 14:57:32 Ben de Groot wrote:
> > On 5 March 2010 09:28, Joshua Saddler <nightmorph@gentoo.org> wrote:
> > > Feel free to submit some documentation patches now that all our docs are
> > > #$!@ed. Thanks.
> > 
> > No need for the drama, my friend. A couple of more choices in
> > profiles does not fuck up all our docs. Some clarification will need
> > to be added to docs that refer to the desktop profile, yes. That's
> > a good point. Let's start identifying which docs need updating.
> > 
> > Cheers,
> 
> I maintain the KDE docs, so I'll update them. I'll also send a doc patch for 
> the gnome and xorg docs. I already blogged about it, and will write the news 
> item. I suppose those are more than enough. Thanks for pointing that out
> -- 
> Theo Chatzimichos (tampakrap)
> Gentoo KDE/Qt Teams
> blog.tampakrap.gr

How about the Handbook? As far as I remember you're asked to choose a profile :-)
I can file a bug it needs to be done :-) Just let me know

-- 
Zeerak Waseem

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

[gentoo-dev] Re: Split desktop profile patches & news item for review

[Duncan]

Zeerak Mustafa Waseem posted on Fri, 05 Mar 2010 18:59:39 +0100 as
excerpted:

> How about the Handbook? As far as I remember you're asked to choose a
> profile :-) I can file a bug it needs to be done :-) Just let me know

That's part 1 (installing), chapter 6 (base system), section 6.b. 
(portage), heading "Choosing the right profile".

The handbook (at least the amd64 handbook I checked, presumably they're 
pretty much the same in this regard) now says to use eselect profile, so 
as long as it's listing the correct choices, the examples and details 
don't matter quite so much.  However, the examples/details do mention 
desktop and server profiles (plus no-multilib for amd64) as alternates to 
the generic arch profile, so they /could/ be changed to additionally 
mention kde and gnome.  But with eselect profile doing the heavy lifting 
already, I'd not call it critical.

But be sure that eselect is getting the correct listing... for all archs. 
=:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: Split desktop profile patches & news item for review

[Theo Chatzimichos]

[-- Attachment #1: Type: Text/Plain, Size: 1570 bytes --]

On Friday 05 March 2010 21:01:09 Duncan wrote:
> Zeerak Mustafa Waseem posted on Fri, 05 Mar 2010 18:59:39 +0100 as
> 
> excerpted:
> > How about the Handbook? As far as I remember you're asked to choose a
> > profile :-) I can file a bug it needs to be done :-) Just let me know
> 
> That's part 1 (installing), chapter 6 (base system), section 6.b.
> (portage), heading "Choosing the right profile".
> 
> The handbook (at least the amd64 handbook I checked, presumably they're
> pretty much the same in this regard) now says to use eselect profile, so
> as long as it's listing the correct choices, the examples and details
> don't matter quite so much.  However, the examples/details do mention
> desktop and server profiles (plus no-multilib for amd64) as alternates to
> the generic arch profile, so they /could/ be changed to additionally
> mention kde and gnome.  But with eselect profile doing the heavy lifting
> already, I'd not call it critical.
> 
> But be sure that eselect is getting the correct listing... for all archs.
> =:^)

I could submit a handbook patch too, but I guess the important thing is to 
make it known to people that are already using the desktop profile. Still, a 
small reference can be made to handbook, but just a small one, as people that 
are going to install KDE or GNOME should refer the relevant installation 
guides. I don't know, Nightmorph has the final word, so I will wait for 
instructions.

BTW, did anyone test it?
-- 
Theo Chatzimichos (tampakrap)
Gentoo KDE/Qt Teams
blog.tampakrap.gr

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

Re: [gentoo-dev] Split desktop profile patches & news item for review

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 648 bytes --]

On Friday 05 March 2010 07:57:32 Ben de Groot wrote:
> On 5 March 2010 09:28, Joshua Saddler <nightmorph@gentoo.org> wrote:
> > Feel free to submit some documentation patches now that all our docs are
> > #$!@ed. Thanks.
> 
> No need for the drama, my friend. A couple of more choices in
> profiles does not fuck up all our docs. Some clarification will need
> to be added to docs that refer to the desktop profile, yes. That's
> a good point. Let's start identifying which docs need updating.

i dont think he's throwing up drama.  he's just posting a friendly reminder 
that any documents referencing profiles are out of date.
-mike

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

Re: [gentoo-dev] Re: Split desktop profile patches & news item for review

[Zeerak Mustafa Waseem]

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

On Fri, Mar 05, 2010 at 07:01:09PM +0000, Duncan wrote:
> Zeerak Mustafa Waseem posted on Fri, 05 Mar 2010 18:59:39 +0100 as
> excerpted:
> 
> > How about the Handbook? As far as I remember you're asked to choose a
> > profile :-) I can file a bug it needs to be done :-) Just let me know
> 
> That's part 1 (installing), chapter 6 (base system), section 6.b. 
> (portage), heading "Choosing the right profile".
> 
> The handbook (at least the amd64 handbook I checked, presumably they're 
> pretty much the same in this regard) now says to use eselect profile, so 
> as long as it's listing the correct choices, the examples and details 
> don't matter quite so much.  However, the examples/details do mention 
> desktop and server profiles (plus no-multilib for amd64) as alternates to 
> the generic arch profile, so they /could/ be changed to additionally 
> mention kde and gnome.  But with eselect profile doing the heavy lifting 
> already, I'd not call it critical.
> 
> But be sure that eselect is getting the correct listing... for all archs. 
> =:^)
> 
> -- 
> Duncan - List replies preferred.   No HTML msgs.
> "Every nonfree program has a lord, a master --
> and if you use the program, he is your master."  Richard Stallman
> 
> 

Agreed, I wouldn't call it a critical thing to edit, however having heard "With so many people confused about profiles as it is", in regards both to the forums and the irc channels, I'd say it should be a priority to make a mention of it. Perhaps something akin to "There are KDE and Gnome specific profiles geared towards each of these desktop environment, should you use another lighter environment the base profile should contain all necessary settings". :-)

-- 
Zeerak Waseem

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

[gentoo-dev] Re: Split desktop profile patches & news item for review

[Theo Chatzimichos]

[-- Attachment #1.1: Type: Text/Plain, Size: 1639 bytes --]

On Thursday 04 March 2010 16:52:50 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 splitted every desktop/ folder i found. The following issues raised
> though: 1) I didn't touch the hardened and selinux directories although
> they do contain a desktop folder. Should I proceed in those or not?
> 2) Some mips/ subdirs don't point to targets/, so I guess the split went to
> /dev/null. So I asked ssuominen who suggested to skip the mips directories,
> and I reverted. (Edit: ssuominen just committed changes in mips profiles in
> tree).
> 3) There were no desktop dirs for bsd/prefix etc.
> 4) Also take a look at how I splitted the USE flags (with ssuominen's and
> yngwin's suggestions) and propose your corrections plz. For example, I
> don't really like the firefox flag in kde, and I'd suggest a -firefox
> (ugly, I know) in kde's make.defaults
> 
> Please Please Please Please Please TEST / REVIEW (especially the arch teams
> plz)
> 
> I'll give three days max for the suggestions here etc, and then I'll
> proceed in creating the news item. So I guess it will be committed in a
> week max. Thanks
> 
> [1] http://git.overlays.gentoo.org/gitweb/?p=proj/kde-crazy.git;a=summary

(I doubt that anyone tested it)

I attached the news item, please review. Meanwhile, I'll create docs patches.

Also, I'm CCing hardened as my No.1 question was not answered. Please do. 
Thanks

PS. Please test it
-- 
Theo Chatzimichos (tampakrap)
Gentoo KDE/Qt Teams
blog.tampakrap.gr

[-- Attachment #1.2: 2010-03-08-new-subprofiles.en.txt --]
[-- Type: text/plain, Size: 1451 bytes --]

Title: New desktop subprofiles for GNOME and KDE
Author: Theo Chatzimichos <tampakrap@gentoo.org>
Content-Type: text/plain
Posted: 2010-03-08
Revision: 1
News-Item-Format: 1.0
Display-If-Profile: default/linux/alpha/10.0/desktop
Display-If-Profile: default/linux/amd64/10.0/desktop
Display-If-Profile: default/linux/arm/10.0/desktop
Display-If-Profile: default/linux/hppa/10.0/desktop
Display-If-Profile: default/linux/ia64/10.0/desktop
Display-If-Profile: default/linux/m68k/10.0/desktop
Display-If-Profile: default/linux/powerpc/ppc32/10.0/desktop
Display-If-Profile: default/linux/powerpc/ppc64/10.0/32bit-userland/desktop
Display-If-Profile: default/linux/powerpc/ppc64/10.0/64bit-userland/desktop
Display-If-Profile: default/linux/powerpc/ppc64/10.0/desktop
Display-If-Profile: default/linux/sh/10.0/desktop
Display-If-Profile: default/linux/sparc/10.0/desktop
Display-If-Profile: default/linux/sparc/experimental/multilib/desktop
Display-If-Profile: default/linux/x86/10.0/desktop

There are two new subprofiles under desktop, one for GNOME and one for
KDE. Users that have only one of those two DEs may choose the according
subprofile. Users of other DEs or WMs may stick to the desktop profile.

Attention: KDE or GNOME specific USE flags have been stripped from the
desktop profile. More specifically:
GNOME subprofile contains: USE="eds evo gnome gstreamer"
KDE subprofile contains: USE="kde"

(I'll commit the change on Monday, 15 Mar 2010)

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

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

[Mart Raudsepp]

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

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

[Peter Hjalmarsson]

mån 2010-03-08 klockan 19:13 +0200 skrev Mart Raudsepp:

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


I vote for this one. A profile being a only contains what is interesting
for that profile, and you can "stash together" some profiles into your
own cocktail.
Yeah, I know it sounds horrible, but it would still be better then to
only be able to focus on one small set.

For example if I am using the GNOME DE, and have someone other also
using my computer, but who really wants to use KDE. Should I have to
find out what from the KDE profile to enable in my env to make my
GNOME-profile also tingle for KDE?

I think having a set of "base profiles" for toolchains and alike (i.e.
default, hardened) would be good. Then be able to add for example
desktop/gnome or server and/or selinux profiles on top would be
interesting. This also for maintainers, as for example PeBenito can
focus on the selinux part of the profiles, and do not have to keep up to
date with which hardened-compilers are currently masked/unmasked.

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

[Alec Warner]

Hehe,

http://dev.gentoo.org/~antarus/essays/mixin-profiles.txt

-rw-r--r-- 1 antarus users 2653 Jun  4  2006 mixin-profiles.txt

-A

On Mon, Mar 8, 2010 at 2:40 PM, Peter Hjalmarsson <xake@rymdraket.net> wrote:
> mån 2010-03-08 klockan 19:13 +0200 skrev Mart Raudsepp:
>
>> 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+.
>>
>
>
> I vote for this one. A profile being a only contains what is interesting
> for that profile, and you can "stash together" some profiles into your
> own cocktail.
> Yeah, I know it sounds horrible, but it would still be better then to
> only be able to focus on one small set.
>
> For example if I am using the GNOME DE, and have someone other also
> using my computer, but who really wants to use KDE. Should I have to
> find out what from the KDE profile to enable in my env to make my
> GNOME-profile also tingle for KDE?
>
> I think having a set of "base profiles" for toolchains and alike (i.e.
> default, hardened) would be good. Then be able to add for example
> desktop/gnome or server and/or selinux profiles on top would be
> interesting. This also for maintainers, as for example PeBenito can
> focus on the selinux part of the profiles, and do not have to keep up to
> date with which hardened-compilers are currently masked/unmasked.
>
>
>
>

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

[Robin H. Johnson]

On Mon, Mar 08, 2010 at 07:13:20PM +0200, Mart Raudsepp wrote:
> 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+.
Consider me to be a huge fan of this idea. I'm already using it with my
managed-portage "system" that I posted some months ago.

Beware that some of the non-Portage PMs don't behave quite right with it
yet. ferringb was working on fixing pkgcore with I had noted to him with
the profiles. I'm not sure about Paludis off the top of my head.

We'd be saving at least 655 inodes on disk (in an rsync copy of the
tree, add another 1k inodes for a CVS checkout).

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

Re: [gentoo-dev] Re: Split desktop profile patches & news item for review

[Ben de Groot]

On 8 March 2010 02:17, Theo Chatzimichos <tampakrap@gentoo.org> wrote:
>
> I attached the news item, please review. Meanwhile, I'll create docs patches.
>
> Also, I'm CCing hardened as my No.1 question was not answered. Please do.
> Thanks

Seeing as there were no further comments, I think we are good to go!

Cheers,
-- 
Ben de Groot
Gentoo Linux developer (qt, media, lxde, desktop-misc)
______________________________________________________

Re: [gentoo-dev] Re: Split desktop profile patches & news item for review

[Mart Raudsepp]

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

On Thu, 2010-03-11 at 02:36 +0100, Ben de Groot wrote:
> On 8 March 2010 02:17, Theo Chatzimichos <tampakrap@gentoo.org> wrote:
> >
> > I attached the news item, please review. Meanwhile, I'll create docs patches.
> >
> > Also, I'm CCing hardened as my No.1 question was not answered. Please do.
> > Thanks
> 
> Seeing as there were no further comments, I think we are good to go!

I suggest reading my comments...

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

Re: [gentoo-dev] Re: Split desktop profile patches & news item for review

[Ben de Groot]

On 11 March 2010 21:20, Mart Raudsepp <leio@gentoo.org> wrote:
> On Thu, 2010-03-11 at 02:36 +0100, Ben de Groot wrote:
>> Seeing as there were no further comments, I think we are good to go!
>
> I suggest reading my comments...

Unless I missed something, you didn't make any comments on this
thread.

If you mean the thread you started that tangentially took off from this
one, about eselect profile improvements: I support that proposal,
but it will take some time to get implemented. Is anyone already
working on that?

In the meantime I see no reason for that to halt or postpone the
current desktop profile improvements as prepared by Theo.

Cheers,
-- 
Ben de Groot
Gentoo Linux developer (qt, media, lxde, desktop-misc)
______________________________________________________

Re: [gentoo-dev] Re: Split desktop profile patches & news item for review

[Mart Raudsepp]

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

On Thu, 2010-03-11 at 23:20 +0100, Ben de Groot wrote:
> On 11 March 2010 21:20, Mart Raudsepp <leio@gentoo.org> wrote:
> > On Thu, 2010-03-11 at 02:36 +0100, Ben de Groot wrote:
> >> Seeing as there were no further comments, I think we are good to go!
> >
> > I suggest reading my comments...
> 
> Unless I missed something, you didn't make any comments on this
> thread.

The subthread got renamed to more fit its purpose.

> If you mean the thread you started that tangentially took off from this
> one, about eselect profile improvements: I support that proposal,
> but it will take some time to get implemented. Is anyone already
> working on that?
> 
> In the meantime I see no reason for that to halt or postpone the
> current desktop profile improvements as prepared by Theo.

I argued that it's a bad idea to add yet more profiles, when we could
avoid that (while even improving things additionally).

But I guess I'll have to bring some direct points why I think
implementing the alternative as I described ASAP is better than ever
doing this gnome/kde subprofile thing:

* The split desktop profile plan retroactively modifies 2008.0 and 10.0
profiles. Not a good thing for obvious reasons. (Of course the
subprofiles could also be added together with a new release, as proposed
for the alternative idea)
* Adding yet more subprofiles, increasing repoman and pcheck time,
possibly confusing users (migration things; changing USE flags in a
perceived stable release profile leading to unexpected --newuse
triggering, etc)
* Making it harder to get both GNOME and KDE things out of a profile
(though the common things in desktop profile right now is quite
suboptimal for GNOME)
* Putting the problem of suboptimal subprofiles handling under the
carpet again, greatly reducing the motivation for people to work on the
alternative better proposal

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

Re: [gentoo-dev] Re: Split desktop profile patches & news item for review

[Theo Chatzimichos]

[-- Attachment #1: Type: Text/Plain, Size: 3331 bytes --]

On Friday 12 March 2010 10:36:57 Mart Raudsepp wrote:
> On Thu, 2010-03-11 at 23:20 +0100, Ben de Groot wrote:
> > On 11 March 2010 21:20, Mart Raudsepp <leio@gentoo.org> wrote:
> > > On Thu, 2010-03-11 at 02:36 +0100, Ben de Groot wrote:
> > >> Seeing as there were no further comments, I think we are good to go!
> > > 
> > > I suggest reading my comments...
> > 
> > Unless I missed something, you didn't make any comments on this
> > thread.
> 
> The subthread got renamed to more fit its purpose.
> 
> > If you mean the thread you started that tangentially took off from this
> > one, about eselect profile improvements: I support that proposal,
> > but it will take some time to get implemented. Is anyone already
> > working on that?
> > 
> > In the meantime I see no reason for that to halt or postpone the
> > current desktop profile improvements as prepared by Theo.
> 
> I argued that it's a bad idea to add yet more profiles, when we could
> avoid that (while even improving things additionally).
> 
> But I guess I'll have to bring some direct points why I think
> implementing the alternative as I described ASAP is better than ever
> doing this gnome/kde subprofile thing:
> 
> * The split desktop profile plan retroactively modifies 2008.0 and 10.0
> profiles. Not a good thing for obvious reasons. (Of course the
> subprofiles could also be added together with a new release, as proposed
> for the alternative idea)
> * Adding yet more subprofiles, increasing repoman and pcheck time,
> possibly confusing users (migration things; changing USE flags in a
> perceived stable release profile leading to unexpected --newuse
> triggering, etc)
> * Making it harder to get both GNOME and KDE things out of a profile
> (though the common things in desktop profile right now is quite
> suboptimal for GNOME)
> * Putting the problem of suboptimal subprofiles handling under the
> carpet again, greatly reducing the motivation for people to work on the
> alternative better proposal


First of all, I'll delay the commit since I need to write documentation 
patches, and I won't be able, as I'll leave soon for a conference and will be 
back on Monday. Maybe I'll find time to prepare something there, but I can't 
promise.

Now, to reply to Mart:

I found your proposal about mixing profiles awesome, and I am willing to work 
on this. In fact, I'm going to raise the issue on KDE's meeting this Thursday 
at 20:00 UTC. Any freedesktop team members will be welcome there. But I'm not 
going to step up from the current workaround I worked on, as things are not 
that tragic. I will document and announce everything, and I will be watching 
forums and IRC for some days to provide support. The only real problem in my 
opinion would be this, people get confused about useflags and unexpected --
newuse results. (btw I already announced it once in my blog, I will do it 
again, and we'll also provide a news item, so I doubt this is even a real 
problem as well). To sum up:
1) Not oblious to me? / Not bad from my point of view?
2) I doubt users will be conflicted, I'll benchmark repoman and hit back
3) agreed, but i don't see a problem there
4) I'll be the motivator for this :)
-- 
Theo Chatzimichos (tampakrap)
Gentoo KDE/Qt Teams
blog.tampakrap.gr

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

Re: [gentoo-dev] Re: Split desktop profile patches & news item for review

[Ben de Groot]

On 12 March 2010 09:36, Mart Raudsepp <leio@gentoo.org> wrote:
> * The split desktop profile plan retroactively modifies 2008.0 and 10.0
> profiles. Not a good thing for obvious reasons.

While I agree with you in principle, this has not been Gentoo practice.
The profiles have already been modified, multiple times, since the
release. So either we need to revert those changes and start a new
profile set (for an upcoming release or whatever), or we need to
solve problems in the current profiles.

I would support a new policy of not changing the release profiles
once they have been officially released, and start working on a new
"current" set of profiles immediately after release (or as soon as
the need for change comes up). So we would in effect have stable
and testing profiles, mirroring our ebuild policy.

> * Adding yet more subprofiles, increasing repoman and pcheck time,
> possibly confusing users (migration things; changing USE flags in a
> perceived stable release profile leading to unexpected --newuse
> triggering, etc)

There are good reasons for these new subprofiles, and I'm sure
our tools can handle them. Documentation and a news item about
the changes should help prevent confusion among users.

> * Making it harder to get both GNOME and KDE things out of a profile
> (though the common things in desktop profile right now is quite
> suboptimal for GNOME)

Either solution is suboptimal, so it is very much about weighing pros
and cons. In my opinion the split desktop profiles are an improvement
over the current situation. And it will be even better when your plan for
eselect profile improvements gets implemented.

> * Putting the problem of suboptimal subprofiles handling under the
> carpet again, greatly reducing the motivation for people to work on the
> alternative better proposal

I think it's rather the other way around: having split gnome and kde
subprofiles makes it all the more apparent that the current handling
of profiles is suboptimal. It will be a bigger motivation for change.

I'm afraid that sweeping the problem of a suboptimal unified desktop
profile under the carpet again by not implementing the split now will
reduce motivation again for people to work on your proposal.

Even so, if we choose not to implement the split now, there are
problems that need addressing in the current situation. The Qt team
finds the mysql dependency that was added to the desktop profile
three months ago (see bug #291996) unacceptable. How would you
propose to solve this without splitting the desktop profile?

Cheers,
-- 
Ben de Groot
Gentoo Linux developer (qt, media, lxde, desktop-misc)
______________________________________________________

[gentoo-dev] Re: Split desktop profile patches & news item for review

[Duncan]

Ben de Groot posted on Fri, 12 Mar 2010 16:47:13 +0100 as excerpted:

>  * Making it harder to get both GNOME and KDE things out of a profile
>> (though the common things in desktop profile right now is quite
>> suboptimal for GNOME)
> 
> Either solution is suboptimal, so it is very much about weighing pros
> and cons. In my opinion the split desktop profiles are an improvement
> over the current situation. And it will be even better when your plan
> for eselect profile improvements gets implemented.

IOW, let's not let the (closer-to-)perfect be the enemy of the good.

That has unfortunately stalled progress before.  Let's not let it happen 
this time.  It's going to take some time to get the new eselect profile 
features coded, tested, and thru the system (including deprecating the old 
version and profiles).  We might as well have the benefit of the spit 
desktop profiles while the ultimate solution's being worked on, especially 
since this one's pretty much ready to go now (days to weeks, including the 
mentioned documentation delay, not months or years).

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: Split desktop profile patches & news item for review

[Ben de Groot]

On 12 March 2010 10:48, Theo Chatzimichos <tampakrap@gentoo.org> wrote:
> First of all, I'll delay the commit since I need to write documentation
> patches, and I won't be able, as I'll leave soon for a conference and will be
> back on Monday.

What exactly needs to be done for documentation? Maybe I can help there.

Cheers,
-- 
Ben de Groot
Gentoo Linux developer (qt, media, lxde, desktop-misc)
______________________________________________________

Re: [gentoo-dev] Re: Split desktop profile patches & news item for review

[Theo Chatzimichos]

[-- Attachment #1: Type: Text/Plain, Size: 670 bytes --]

On Friday 12 March 2010 19:39:48 Ben de Groot wrote:
> On 12 March 2010 10:48, Theo Chatzimichos <tampakrap@gentoo.org> wrote:
> > First of all, I'll delay the commit since I need to write documentation
> > patches, and I won't be able, as I'll leave soon for a conference and
> > will be back on Monday.
> 
> What exactly needs to be done for documentation? Maybe I can help there.
> 
> Cheers,

KDE guide needs update (I'll do that) and also GNOME and xorg guides, and 
maybe the handbook (i'm still waiting for a confirmation by the docs team for 
that). Thanks for the offer

-- 
Theo Chatzimichos (tampakrap)
Gentoo KDE/Qt Teams
blog.tampakrap.gr

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

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

[Brian Harring]

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

On Mon, Mar 08, 2010 at 11:40:00PM +0100, Peter Hjalmarsson wrote:
> mån 2010-03-08 klockan 19:13 +0200 skrev Mart Raudsepp:
> 
> > 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+.
> > 
> 
> 
> I vote for this one. A profile being a only contains what is interesting
> for that profile, and you can "stash together" some profiles into your
> own cocktail.
> Yeah, I know it sounds horrible, but it would still be better then to
> only be able to focus on one small set.
> 
> For example if I am using the GNOME DE, and have someone other also
> using my computer, but who really wants to use KDE. Should I have to
> find out what from the KDE profile to enable in my env to make my
> GNOME-profile also tingle for KDE?
> 
> I think having a set of "base profiles" for toolchains and alike (i.e.
> default, hardened) would be good. Then be able to add for example
> desktop/gnome or server and/or selinux profiles on top would be
> interesting. This also for maintainers, as for example PeBenito can
> focus on the selinux part of the profiles, and do not have to keep up to
> date with which hardened-compilers are currently masked/unmasked.

While I agree in principle within mixins, no one here is discussing 
the QA affect of it- right now we can do visibility scans of 
combinations of gnome + amd64 + 2010 because they're defined.

If there is a shift to having users do the combinations themselves 
(rather then combining w/in tree), there won't be visibility scans for 
it- end result, more broken deps should be able to slide by, more 
horked cycles, etc.

A solution there would be useful- one that preferably doesn't involve 
scanning every possible permutation of mixable profiles (you would 
*not* like the speed affect that would have on repoman).
~harring

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

Re: [gentoo-dev] Re: Split desktop profile patches & news item for review

[Mart Raudsepp]

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

On Fri, 2010-03-12 at 16:47 +0100, Ben de Groot wrote:
> 
> Even so, if we choose not to implement the split now, there are
> problems that need addressing in the current situation. The Qt team
> finds the mysql dependency that was added to the desktop profile
> three months ago (see bug #291996) unacceptable. How would you
> propose to solve this without splitting the desktop profile?

Probably by solving the issue there. Either not requiring a mysql USE
flag in the relevant places, or USE defaulting it on there for now for
just that package; or package.use enabled in desktop profile, instead of
globally.



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

Re: [gentoo-dev] Re: Split desktop profile patches & news item for review

[Mart Raudsepp]

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

On Fri, 2010-03-12 at 11:48 +0200, Theo Chatzimichos wrote:
> I found your proposal about mixing profiles awesome, and I am willing to work 
> on this. In fact, I'm going to raise the issue on KDE's meeting this Thursday 
> at 20:00 UTC. Any freedesktop team members will be welcome there. But I'm not 
> going to step up from the current workaround I worked on, as things are not 
> that tragic. I will document and announce everything, and I will be watching 
> forums and IRC for some days to provide support. The only real problem in my 
> opinion would be this, people get confused about useflags and unexpected --
> newuse results. (btw I already announced it once in my blog, I will do it 
> again, and we'll also provide a news item, so I doubt this is even a real 
> problem as well).

I guess it's a question of how long the other proposal takes
implementing. If just a month or two, two migration within that time
period doesn't make so much sense. If we really estimate slow progress
there, then I guess we can have users deal with the multiple migrations
and some months of small benefits from the better profiles.
Just this situation with desktop profiles has existed for as long as
desktop profile have existed, so waiting a couple months more for the
perfect solution (while avoiding multiple migrations) doesn't sound like
a bad idea to me.

I appreciate you intending to take a lead on pushing the other proposal
too.

I guess I should review the gnome subprofile soon, I assume some of our
other guys already did though.

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

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

[Mart Raudsepp]

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

On Sat, 2010-03-13 at 13:16 -0800, Brian Harring wrote:
> On Mon, Mar 08, 2010 at 11:40:00PM +0100, Peter Hjalmarsson wrote:
> > mån 2010-03-08 klockan 19:13 +0200 skrev Mart Raudsepp:
> > 
> > > 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+.
> > > 
> > 
> > 
> > I vote for this one. A profile being a only contains what is interesting
> > for that profile, and you can "stash together" some profiles into your
> > own cocktail.
> > Yeah, I know it sounds horrible, but it would still be better then to
> > only be able to focus on one small set.
> > 
> > For example if I am using the GNOME DE, and have someone other also
> > using my computer, but who really wants to use KDE. Should I have to
> > find out what from the KDE profile to enable in my env to make my
> > GNOME-profile also tingle for KDE?
> > 
> > I think having a set of "base profiles" for toolchains and alike (i.e.
> > default, hardened) would be good. Then be able to add for example
> > desktop/gnome or server and/or selinux profiles on top would be
> > interesting. This also for maintainers, as for example PeBenito can
> > focus on the selinux part of the profiles, and do not have to keep up to
> > date with which hardened-compilers are currently masked/unmasked.
> 
> While I agree in principle within mixins, no one here is discussing 
> the QA affect of it- right now we can do visibility scans of 
> combinations of gnome + amd64 + 2010 because they're defined.

What sort of QA affects do you imagine it having?
Though I'm talking in the context of what I proposed - using it for just
the target profiles that only tweak USE flags and other such defaults,
nothing else. I considered QA affects for that case, at least in my own
thoughts. I think QA would be checked anyhow there, as part of all USE
flags enabled assumpting testing or static testing of various USE flag
combinations of a package (e.g, for statically finding circular
dependencies or the like).

If you put selinux and toolchains in the mix, that indeed could be
problematic to QA. Though one could probably define some profiles
somewhere that would get used for QA testing, but not exposed to users.

Do you foresee bad QA affects for the for the
desktop/developer/gnome/kde/server profiles case too, or just when
mixing in selinux/toolchains/etc?

> If there is a shift to having users do the combinations themselves 
> (rather then combining w/in tree), there won't be visibility scans for 
> it- end result, more broken deps should be able to slide by, more 
> horked cycles, etc.
> 
> A solution there would be useful- one that preferably doesn't involve 
> scanning every possible permutation of mixable profiles (you would 
> *not* like the speed affect that would have on repoman).
> ~harring

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

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

[Brian Harring]

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

On Sun, Mar 14, 2010 at 02:02:46AM +0200, Mart Raudsepp wrote:
> On Sat, 2010-03-13 at 13:16 -0800, Brian Harring wrote:
> > While I agree in principle within mixins, no one here is discussing 
> > the QA affect of it- right now we can do visibility scans of 
> > combinations of gnome + amd64 + 2010 because they're defined.
> 
> What sort of QA affects do you imagine it having?

Simple enough.  Right now, you change a profile, or want to stable a 
pkg, you can do a scan and identify all new visibility issues from 
profiles- you can validate up front that for the list of 
supported/stable profiles, these changes occur.

If things are shifted over to prefering users mixing/matching profiles 
on their own (meaning we no longer have a gnome amd64 2010 for 
example), devs no longer get QA warnings when they break stuff for it.

Users see it however.

> Though I'm talking in the context of what I proposed - using it for just
> the target profiles that only tweak USE flags and other such defaults,
> nothing else.

Current QA (repoman/pcheck), if a use flag is defaulted on, it's deps 
in a pkg must be visible.  Via repoman/pcheck, they ensure that the 
default use configuration for a profile, all visible pkgs dependencies 
are visible (making the pkg fully usable).

Consider mixing/matching gnome/kde with a profile that has quite a few 
packages masked- say mips.  To be clear, this is a hypothetical case- 
I know it exists, I'm just choosing two likely targets.  Say gnome 
requires some codecs use flag flipped on triggering a dep on a pkg 
masked for mips.

I'm not saying these situations can't be worked around- we already fix 
them now as they come up.  The thing is, whenever you change something 
now, those profile combinations are validated- with mix/match 
approach, that validation won't be occuring, the users will be the 
ones seeing the breakage rather than the dev.

> I considered QA affects for that case, at least in my own
> thoughts. I think QA would be checked anyhow there, as part of all USE
> flags enabled assumpting testing or static testing of various USE flag
> combinations of a package (e.g, for statically finding circular
> dependencies or the like).

Either you're suggesting that repoman/pcheck would have to scan all 
arbitrary combinations of gnome/kde/desktop w/ misc arches, or you 
need to be a fair bit more precise about how QA tools would identify 
what profile combinations to check.

If you're proposing that the QA tool arbitrarily combines arches w/ 
various desktop/server mixins, I'll again note that the run time of 
visibility scans is directly related to # of profiles to check- for 
example, removal of mips profiles from profiles.desc is if memory 
serves me a ~33% reduction in visibility runtime for pcheck.

For repoman (which all devs have to use for commiting), # of profiles 
is even more of a critical value performance wise.


> Do you foresee bad QA affects for the for the
> desktop/developer/gnome/kde/server profiles case too, or just when
> mixing in selinux/toolchains/etc?

Issues will exist regardless of what the combination is.  The point 
I'm making is that with the current model, we catch those issues prior 
to commit- having users mix/match on their own means users will see 
those issues rather than devs.  Literally, they'll see the breakage.

~harring

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

[gentoo-dev] Re: Split desktop profile patches & news item for review

[Theo Chatzimichos]

[-- Attachment #1: Type: Text/Plain, Size: 2078 bytes --]

On Monday 08 March 2010 03:17:57 Theo Chatzimichos wrote:
> On Thursday 04 March 2010 16:52:50 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 splitted every desktop/ folder i found. The following issues raised
> > though: 1) I didn't touch the hardened and selinux directories although
> > they do contain a desktop folder. Should I proceed in those or not?
> > 2) Some mips/ subdirs don't point to targets/, so I guess the split went
> > to /dev/null. So I asked ssuominen who suggested to skip the mips
> > directories, and I reverted. (Edit: ssuominen just committed changes in
> > mips profiles in tree).
> > 3) There were no desktop dirs for bsd/prefix etc.
> > 4) Also take a look at how I splitted the USE flags (with ssuominen's and
> > yngwin's suggestions) and propose your corrections plz. For example, I
> > don't really like the firefox flag in kde, and I'd suggest a -firefox
> > (ugly, I know) in kde's make.defaults
> > 
> > Please Please Please Please Please TEST / REVIEW (especially the arch
> > teams plz)
> > 
> > I'll give three days max for the suggestions here etc, and then I'll
> > proceed in creating the news item. So I guess it will be committed in a
> > week max. Thanks
> > 
> > [1] http://git.overlays.gentoo.org/gitweb/?p=proj/kde-crazy.git;a=summary
> 
> (I doubt that anyone tested it)
> 
> I attached the news item, please review. Meanwhile, I'll create docs
> patches.
> 
> Also, I'm CCing hardened as my No.1 question was not answered. Please do.
> Thanks
> 
> PS. Please test it

News item commited, also added note to KDE guide and proposed note for GNOME 
FAQ. I didn't find anything relevant about profiles in xorg guide so I skipped 
it. I'll commit this change this Friday, 26 March

@ Docs Team, do you want a handbook patch? I don't think it is needed, but 
whatever you say
-- 
Theo Chatzimichos (tampakrap)
Gentoo KDE/Qt Teams
blog.tampakrap.gr

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