Re: [gentoo-dev] Re: 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 pgp96WQbGx4Qb.pgp Description: PGP signature
Re: [gentoo-dev] Re: Reorganizing handling of target specific profiles (Was: Split desktop profile patches news item for review)
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: l...@gentoo.org Weblog: http://blogs.gentoo.org/leio signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: 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 pgpMhGs1sARlW.pgp Description: PGP signature
[gentoo-dev] Re: 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.
Re: [gentoo-dev] Re: Reorganizing handling of target specific profiles (Was: Split desktop profile patches news item for review)
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 x...@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.
