FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 03-08-2010, 09:40 PM
Peter Hjalmarsson
 
Default Reorganizing handling of target specific profiles (Was: Split desktop profile patches & news item for review)

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.
 
Old 03-09-2010, 12:26 AM
"Robin H. Johnson"
 
Default Reorganizing handling of target specific profiles (Was: Split desktop profile patches & news item for review)

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
 
Old 03-13-2010, 08:16 PM
Brian Harring
 
Default Reorganizing handling of target specific profiles (Was: Split desktop profile patches & news item for review)

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
 
Old 03-14-2010, 04:25 AM
Brian Harring
 
Default Reorganizing handling of target specific profiles (Was: Split desktop profile patches & news item for review)

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
 

Thread Tools




All times are GMT. The time now is 06:18 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org