On Mon, 2005-08-29 at 15:32 -0500, Brian Harring wrote: > On Mon, Aug 29, 2005 at 12:56:35PM -0400, Chris Gianelloni wrote: > > On Sat, 2005-08-27 at 05:01 -0500, Brian Harring wrote: > > Basically, you've taken then 2005.1 profile and made it useless, since > > the stages weren't built against it anyway.
> Via that logic (don't change it lest it negates a release), we would > never be able to do changes, or would be forced to do changes strictly > whenever y'all are doing a new release. Not exactly. I tend to agree with you that the base arch profiles should be a fairly minimal set of defaults, but also, default-linux has always been tied to releases, as much as possible. The point is that we really should *not* be making changes without media that matches it. Take the recent "eds gstreamer" thread as a good example. People expect a release to have changes. They don't expect, and don't *want* their system to change underneath them. If I had my way, there wouldn't ever be changes made to any of the profiles, including the arch profiles, unless absolutely necessary, and all changes would go into versioned (or named and versioned, or just named, etc) sub-profiles. The only thing that has kept us from doing this already is the lack of multiple inheritance. > Profiles aren't bound to the releases, despite how people may view it > and/or the current profile maitnainer's usage of 'em. No, they are not. I never said that they were, either. That being said, it ends up being the release team that ends up getting the bugs for the profiles. While there are a small number of developers that will change profiles under default-linux, it is more often than not left up to each arch's release coordinator. There are also non-release profiles on a few arches. There's nothing stopping you from creating a default-linux/x86/ferringb profile and doing whatever you wish in it, but editing default-linux/x86/2005.1 without speaking with releng would be considered taboo. > > My point is pretty simple, > > why should we spend a bunch of time maintaining something that is > > designed from the start to be customized, and most likely won't even be > > used anyway? > That's the issue; the profiles in their current form are customizable > only in the ability to negate a collection of flags. > Negating the whole beast is another story due to the desktop cruft > being shoved into the arch subprofiles. Sorry, but this didn't make a bit of sense to me. Perhaps you could reword it? > > I would much rather stick with the "2005.1" profile > > meaning "what we used to build 2005.1" than having it mean "some > > variation of 2005.1 is below here and using this profile is minimal and > > likely won't do what you expect". > Again, releases may be bound by available profiles, but available profiles > are not bound by available releases. Nobody ever said that profiles were bound to releases. I said that the versioned profile should match the release it was used to build and nothing more. Please don't insert meaning into what I say. > Aside from that, the comments about variations/minimal/not doing what > you expect, what do you think USE="-* user's actual desired flags" > accomplishes? It accomplishes exactly what I think it does. It turns off all automatically-enabled USE flags. I use it personally, because I run with a much smaller set of USE flags and I don't want things being changed without my knowledge. That being said, I also understand that this means I need to spend some time maintaining my systems and checking for the inclusion of new flags when I merge packages or do upgrades. > Profile customization occurs, /etc/portage/profiles exists for this > reason; the 2005.1 profile (fex) is probably *rarely* ran exactly as > y'all have it specified considering we do have user level use flags, > tweaking the hell out of '05.1. You would be surprised at the number of people that use GRP and rarely, if ever, change their USE flags. I wish I had numbers, but I don't. Anyway, the default set of USE flags seems to be a pretty perfect mix for most people. It gives packages that work as expected, and is geared toward a desktop system. Without any more specific examples of what you're trying to point out, I'm just not seeing it. > Aside from mild disagreement on views, as was stated in previous > emails, multiple inheritance I tend to think is required to minimize > the work for y'all; what I want you guys to do (or I'll do myself) is > chunk the suckers up so people after a minimal base for running > it themselves, or building up their own subprofile can do so. Not > after jamming maintenance nightmares on you, which without multiple > inheritance, might be a bit. I know that I won't be spending *my* time making any profile other than the defaults used for building the release. Anyone is welcome to build profiles for anything else that they might want, but since the release team doesn't use it, we shouldn't be forced to waste our time on it. -- Chris Gianelloni Release Engineering - Strategic Lead/QA Manager Games - Developer Gentoo Linux
signature.asc
Description: This is a digitally signed message part
