Re: [gentoo-dev] Re: [gentoo-core] crap use flags in the profiles
Brian Harring wrote: The thing to note is that if you're relying on negation, it's going to bite you in the ass without efforts. A server subprofile pulling from a parent that holds desktop cruft will be forced to either A) reinvent the wheel (maintain their own USE list), as a sizable chunk of users do via -* usage B) or very carefully watch people screwing around with the parent, tagging in a new desktop USE var, and adding the matching negation. One would hope that some minimal effort of communication to the maintainers of inheriting profiles by people changing the ancestor profiles would prevent the need for this. Donnie -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: [gentoo-core] crap use flags in the profiles
On Tuesday 30 August 2005 23:36, Stephen Bennett wrote: On Tue, 30 Aug 2005 16:45:24 -0400 Olivier Crete [EMAIL PROTECTED] wrote: You are comparing apples and oranges.. Most of the herd devs only have x86 and are not able to test amd64. That's the main difference. Most of the mips devs only have 64-bit big endian SGI hardware, and aren't able to test on little-endian systems. Endianness issues are at least as big a problem as 64-bit issues when porting software. This architecture however has the advantage that most upstream software is written for 32 bit little endian (read x86) systems. Most times using 64bit big endian weeds out the cases where upstream developers made incorrect assumptions on the architecture. As such, when it works on such a system it's likely to work on variations too that are 32bit or little endian. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpIJDpGG53Fm.pgp Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-core] crap use flags in the profiles
Stephen Bennett wrote: [Tue Aug 30 2005, 11:26:40AM CDT] With your experience what are the pro and cons of merging different archs ? Fewer different keywords to manage makes for easier maintenance in most cases. If mips had 6 different keywords for different ABIs/endianness we'd never get anything done. For me, one problem with merging amd64 and x86 the way that the mips folks handle their various flavors is the not-so-minor fact that I have no idea how mips does whatever magic they do to make things work, so all I can do right now is say That sounds like a good idea in principle, but, gosh, it sounds awfully hard! Perhaps this discussion might actually go somewhere useful if people could be pointed to how one makes this sort of thing work in practice? I'm more than happy to read the fine manual, once I know which one that is -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpiiNphkPsfZ.pgp Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-core] crap use flags in the profiles
Brian Harring wrote: On Mon, Aug 29, 2005 at 05:43:35PM -0400, Chris Gianelloni wrote: snip Re: not shoving work onto you, complicating your job, etc, I agree, and actually is what I was getting at in the badly worded section below 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? Basically stating that if I want the minimal 2005.1 x86 profile to build my own server profile off of, I can't really use the existing default-linux/x86/2005.1 ; Why? Mainly due to the fact that I would be forced to reverse a *lot* of stuff, use flags mainly, to get it back down to a minimal profile. That's what I mean by lack of customization; it can be done, but it's not optimal, vs say inheriting a base default/x86/2005.1 that holds just system defaults (pam, cflags, etc). If I were to implement a server profile from existing, I'd probably tag in -* to the use, and add the use flags I explicitly want; that's not really the best way to use the profiles inheritance capabilities though :) 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. Key thing to note, neither of us have figures :) Beyond that, I'm not after castrating the defaults that exist, I'm after sticking a level of indirection, a subprofile into the releng profile inheritance chain so that if I *want* a minimal profile (as you use), I can get it without having to resort to -* and tracking all of the changes myself. It's a time saving effort; add multiple inheritance in, and it's easy to do (win/win). It'd be very handy , what if we setup a limit of subprofiles so to avoid people requesting other subprofiles?, and at the same time we can take more advantage of this idea? For example, we could have, a minimal, a default, and a custom subprofile. minimal would contain , well, as the word says, the minimal configuration, so everyone willing to have only USE=-* basic-stuff , can get it out of the box. default would be the profile which releng link the releases against. Our current profile. custom would be some way of people to tweak and do whatever they want .. this would be more like a way to give some kind of organization. With this kind of structure, we are still pretty general to fall into a I want a Gnome profile , but we can still take advantage of the feature for specific needs, and makes easier in such a way. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: [gentoo-core] crap use flags in the profiles
On Mon, 2005-08-29 at 17:34 -0500, Brian Harring wrote: Basically stating that if I want the minimal 2005.1 x86 profile to build my own server profile off of, I can't really use the existing default-linux/x86/2005.1 ; Ehh... There *is* no minimal 2005.1 profile. That has always been the point. The 2005.1 profile is what we used for 2005.1 not minimal set of bull that can build a machine on x86 that just happens to coincide with the 2005.1 release. If you want a minimal profile, make one. Why? Mainly due to the fact that I would be forced to reverse a *lot* of stuff, use flags mainly, to get it back down to a minimal profile. That's what I mean by lack of customization; it can be done, but it's not optimal, vs say inheriting a base default/x86/2005.1 that holds just system defaults (pam, cflags, etc). USE flags *only*, actually. Also, we haven't been building the profiles to be optimal for customization. We have been building them to just work for the most people. If I were to implement a server profile from existing, I'd probably tag in -* to the use, and add the use flags I explicitly want; that's not really the best way to use the profiles inheritance capabilities though :) I'll agree with you here. Like I said, the x86 profile stuff, since *at least* 2004.0's and the beginning of cascades, has had all of this cruft in there already. Of course, I also don't think that a server profile should inherit from the current default-linux sub-profiles anyway, as they are more geared towards end-user machines, and instead should inherit from default-linux (possibly, maybe even just base) themselves and build up a very specific configuration for servers. Basically, you're saying that a whole ton of crap should be under default-linux, where I think nothing should really be under there except for the default profiles, and other profiles should have their own top-level, just like hardened or uclibc does. 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. Key thing to note, neither of us have figures :) Beyond that, I'm not after castrating the defaults that exist, I'm after sticking a level of indirection, a subprofile into the releng profile inheritance chain so that if I *want* a minimal profile (as you use), I can get it without having to resort to -* and tracking all of the changes myself. I have no problem with that. Check out profiles/default-linux/x86/dev and see if it would meet your needs. It does *not* inherit from x86, but from default-linux, so it is geared to be an x86 replacement. This would keep everything else in the sub-profiles, such as 2005.1, etc. Basically, if you wanted a server profile, you'd inherit from profiles/default-linux/x86, not profiles/default-linux/x86/2005.1, since the 2005.1 profile would have all the desktop stuff. It's a time saving effort; add multiple inheritance in, and it's easy to do (win/win). Agreed. With multiple inheritance, we all win, but see if this at least helps for now. I have no problem right now making the changes necessary (to x86, at least) to make the base arch profile minimal for you. 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. Agreed, although I'd posit that when/if multiple inheritance is added, y'all take advantage of it (break up the settings into base and desktop) so that others can use your base work instead of reinventing the wheel. That would be fine by me. -- Chris Gianelloni Release Engineering - Strategic Lead/QA Manager Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: [gentoo-core] crap use flags in the profiles
On Mon, 2005-08-29 at 20:42 -0400, Alec Warner wrote:
No. *I* could not because *I* think it is a waste of time. I care
about exactly one profile, in honesty, the one I use to build the
release. If there were 10,000 other profiles, I wouldn't care.
and *I* can't make a tree-wide server profile because *I* don't have a)
commit access and b) a minimal profile to derive from other than
default-linux, and thats yours and you said you will not let it be
changed. Plus default-linux is far too minimal. So *I* have to jump on
-dev and convince others ( not necessarily you, mind ) that a profile of
this nature is a good idea, so *I* don't end up having to duplicate tons
of work making a default profile for every arch I run.
a) not my problem... ;]
b) default-linux isn't mine... default-linux/x86/2005.1 is... get the
distinction now?
A server profile should be separate anyway. It shouldn't have
*anything* to do with the release profiles, since we aren't releasing
it. This seems to be the point everyone is missing. There's nothing
stopping anyone from making as many profiles to do as many things as
they want, I simply ask them to not muck with the release's dated
profiles.
you could also do default-linux/x86/2005.1/release or whatnot if you want
to maintain that as well.
Why? Would you not expect the 2005.1 Handbook plus the 2005.1 media
plus the 2005.1 profile to produce a 2005.1 system? Why would I need a
release sub-profile to distinguish it as a release? Is that not
completely redundant?
The plan with having a release sub-profile was making the
default-linux/${ARCH}/${RELEASE}/ a minimal profile and then have the
/release subprofile be 'normal', and taking a second look really no
different from a desktop subprofile other than better naming.
No.
I have no problem with making the default-linux/${ARCH} profile minimal,
as I tend to agree that it should be, but the dated profiles should
match what is released. Doing anything else really is plain asinine as
the 2005.1 stage tarball should match the 2005.1 profile. Or would
you rather we start calling the tarballs 2005.1-release, which is
*really* redundant?
as far as profiles, there is no documentation that I can find on who
'owns' profiles and does work on them. Sorry if you end up doing all
Nobody really owns them, at all. In general, the arch teams maintain
their own. Nobody touches default-linux unless absolutely necessary.
For the x86 profiles, releng has been maintaining them since it was
born, with a few people interjecting fixes here and there.
the work on default-linux, I will focus my efforts elsewhere if that is
the case. I just know that for the majority of profiles
default-linux/arch is what most of them inherit from, so thats where the
party started ;)
Most of the profiles are also based on the idea of being modifications
or extensions from the release's profiles. You're talking about
something completely divergent.
Notice something with me. When you look for the hardened profiles, you
don't look under profiles/default-linux/${ARCH}/${RELEASE}/hardened, do
you? Why not? Because they're divergent enough that doing the
inheritance from a release profile makes it more work than not. It's
really that simple. Nobody would have a problem with them using
profiles/default-linux/${ARCH}/${RELEASE}/hardened. They don't because
it doesn't make sense for them to do so. I tend to think any server
profiles would fall under the same thinking.
--
Chris Gianelloni
Release Engineering - Strategic Lead/QA Manager
Games - Developer
Gentoo Linux
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] Re: [gentoo-core] crap use flags in the profiles
Shouldn't this fall under the x86 arch team rather than releng? The I'm sorry, but *what* x86 arch team? That's the point. Ciaran is just pointing out for the gazillionth time that x86 is an unsupported arch, if you go by the standards the other arches have to follow to be part of Gentoo. When is this going to be fixed? Or, will it just be ignored until all the x86 folks get amd64 machines and x86 pretty much becomes irrelevant? Is this also a good time to note that the amd64 and x86 could *easily* be covered under the same keyword? We cover a large variety of mips machines/userlands under one keyword, with differences much more significant then that between x86 and amd64. -Steve -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: [gentoo-core] crap use flags in the profiles
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Is this also a good time to note that the amd64 and x86 could *easily* be covered under the same keyword? We cover a large variety of mips machines/userlands under one keyword, with differences much more significant then that between x86 and amd64. Sorry I disagree with this, differences exists and sometimes are a problem. Some package and library don't compile cleanly under amd64 arch. On few but existant cases it's good to have two different archs. Not even going near the analizing the differences in the profiles. rgs, Francesco -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDFHTN1wNBTLVPMuARAkCpAJ4gkQQ9Ntp9j5dsldyFLLt1lj/iTgCfahlF avwo9tHBaW1LTWWPeLPDFO4= =yYUZ -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: [gentoo-core] crap use flags in the profiles
Is this also a good time to note that the amd64 and x86 could *easily* be covered under the same keyword? We cover a large variety of mips machines/userlands under one keyword, with differences much more significant then that between x86 and amd64. Sorry I disagree with this, differences exists and sometimes are a problem. Some package and library don't compile cleanly under amd64 arch. On few but existant cases it's good to have two different archs. Not even going near the analizing the differences in the profiles. So these things won't compile in a x86 chroot on a amd64 box even? I find that really hard to believe. Besides, close collaboration between folks with x86 and folks with amd64 installs can make it easy to ensure the same versions work on both arches (if you really want to call them separate arches...) Your profile argument is silly too, since both arches could *easily* be merged into sub-profiles in our cascading system. Besides, we have the same sorts of problems on mips, except they are magnified since we have a possibility of 3 different userland ABIs, on both big and little endian hardware. After dealing with this sort of stuff for a long time with *far* fewer developers and time in general, I'm really not impressed with your argument. You'll have to do better then that. -Steve -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: [gentoo-core] crap use flags in the profiles
On Tue, 2005-30-08 at 10:46 -0400, Stephen P. Becker wrote: Shouldn't this fall under the x86 arch team rather than releng? The I'm sorry, but *what* x86 arch team? That's the point. Ciaran is just pointing out for the gazillionth time that x86 is an unsupported arch, if you go by the standards the other arches have to follow to be part of Gentoo. When is this going to be fixed? Or, will it just be ignored until all the x86 folks get amd64 machines and x86 pretty much becomes irrelevant? Stop being jealous and get a Dell dude. -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer x86 Security Liaison -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: [gentoo-core] crap use flags in the profiles
On Tue, 2005-08-30 at 17:01 +0200, Francesco R wrote: Is this also a good time to note that the amd64 and x86 could *easily* be covered under the same keyword? We cover a large variety of mips machines/userlands under one keyword, with differences much more significant then that between x86 and amd64. Sorry I disagree with this, differences exists and sometimes are a problem. Some package and library don't compile cleanly under amd64 arch. On few but existant cases it's good to have two different archs. Not even going near the analizing the differences in the profiles. Actually, they're correct. Both amd64 and x86 could be controlled by the same keyword. The problem really lies in the knowledge base of our developers. I'm not knocking anyone, but if you haven't run on a 64-bit architecture, then you wouldn't understand how to troubleshoot and fix issues with it. -- Chris Gianelloni Release Engineering - Strategic Lead/QA Manager Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: [gentoo-core] crap use flags in the profiles
Stephen P. Becker wrote:
Is this also a good time to note that the amd64 and x86 could
*easily* be covered under the same keyword? We cover a large
variety of mips machines/userlands under one keyword, with
differences much more significant then that between x86 and amd64.
Sorry I disagree with this, differences exists and sometimes are a
problem. Some package and library don't compile cleanly under amd64
arch.
On few but existant cases it's good to have two different archs. Not
even going near the analizing the differences in the profiles.
So these things won't compile in a x86 chroot on a amd64 box even?
Never said this, I've a dual opteron running informix that can *only*
run under a x86 environment.
this is the profile for the main environment:
make.profile - ../usr/portage/profiles/default-linux/amd64/2005.0
and this one for the chroot:
/chroot/ifx/etc/make.profile -
../usr/portage/profiles/default-linux/x86/2004.0/
They are covered from completely different keywords and profiles.
I find that really hard to believe. Besides, close collaboration
between folks with x86 and folks with amd64 installs can make it easy
to ensure the same versions work on both arches (if you really want to
call them separate arches...) Your profile argument is silly too,
since both arches could *easily* be merged into sub-profiles in our
cascading system.
Maybe I've not understud the first sentence, what are you saying is that
amd64 teams can do x86 testing, we agree on this (all not kernel related).
profiles: /usr/portage/profiles/default-linux{/amd64/2005.1/ ,
x86/2005.1/} looks rather different to me (not analized them deeply)
Besides, we have the same sorts of problems on mips, except they are
magnified since we have a possibility of 3 different userland ABIs, on
both big and little endian hardware. After dealing with this sort of
stuff for a long time with *far* fewer developers and time in general,
I'm really not impressed with your argument. You'll have to do better
then that.
With your experience what are the pro and cons of merging different archs ?
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: [gentoo-core] crap use flags in the profiles
On Tue, 30 Aug 2005 17:46:20 +0200 Francesco R [EMAIL PROTECTED] wrote: Never said this, I've a dual opteron running informix that can *only* run under a x86 environment. this is the profile for the main environment: make.profile - ../usr/portage/profiles/default-linux/amd64/2005.0 and this one for the chroot: /chroot/ifx/etc/make.profile - ../usr/portage/profiles/default-linux/x86/2004.0/ They are covered from completely different keywords and profiles. So it runs fine on amd64, but only with the 32-bit ABI. With your experience what are the pro and cons of merging different archs ? Fewer different keywords to manage makes for easier maintenance in most cases. If mips had 6 different keywords for different ABIs/endianness we'd never get anything done. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: [gentoo-core] crap use flags in the profiles
On Tue, 2005-08-30 at 11:24 -0400, Stephen P. Becker wrote:
Is this also a good time to note that the amd64 and x86 could
*easily* be covered under the same keyword? We cover a large
variety of mips machines/userlands under one keyword, with
differences much more significant then that between x86 and amd64.
Sorry I disagree with this, differences exists and sometimes are a
problem. Some package and library don't compile cleanly under amd64 arch.
On few but existant cases it's good to have two different archs. Not
even going near the analizing the differences in the profiles.
So these things won't compile in a x86 chroot on a amd64 box even? I
find that really hard to believe. Besides, close collaboration between
folks with x86 and folks with amd64 installs can make it easy to ensure
the same versions work on both arches (if you really want to call them
separate arches...) Your profile argument is silly too, since both
arches could *easily* be merged into sub-profiles in our cascading system.
Besides, we have the same sorts of problems on mips, except they are
magnified since we have a possibility of 3 different userland ABIs, on
both big and little endian hardware. After dealing with this sort of
stuff for a long time with *far* fewer developers and time in general,
I'm really not impressed with your argument. You'll have to do better
then that.
-Steve
I agree that merging the two profiles is something to aspire to (see the
recent ppc/ppc64 profile merge as an example. However merging the
keywords can lead to trouble. Speaking only for ppc/ppc64 there are
times when there are very specific ppc64 compiler problems that, if we
shared a keyword, leave a large portion of the tree keyworded for
stability but in a You can only compile this program in a 32-bit
chroot state. I would rather make a clear cut statement that these apps
only function in a 32-bit env then give the user the impression that
they work out of the box.
Take for example Mozilla, Firefox, and OpenOffice none of these function
on ppc64 (yet) but they function without issue on ppc. It is only within
the last few months that Mozilla even got a ~ppc64 keyword (and not
because it works, all it does at the moment is launch a window).
Just to give you an idea. Last I looked (a week or so ago) the number of
ppc stable keyworded packages outnumbered the ppc64 ones by almost 3:1.
Now some of this is just due to a lack of manpower to test all those
packages, and some of it is due to a lack of end-user interest in those
packages on the ppc64 platform but I can guarantee that some of them
also suffer ppc64 specific bugs. Until the stable list matches at least
90% I personally would be unwilling to merge the keywords. If we ever
get to that point I think the remaining packages could be dealt with on
a case by case basis when users tripped over them. After that we could
deal with new packages in a coordinated way making sure that they work
on both platforms together.
I also don't buy the argument that the user has to be educated on how to
change their ABI midstream if something breaks under one or the other on
a mainstream arch. I am of the stong opinion that things should just
work, 100% of the time. That means that for each set (ppc/ppc64
x86/amd64) the ebuilds have to be gone over and modified to use the
appropriate abi internally. Mips is slightly different as it is a niche
architecture with a smaller, arguably better educated in the ways of gcc
etc., user base.
I don't know what the ratio is for amd64 and x86 (I suspect far better
then ppc64 vs. ppc as the dev/user base is far larger) but I think that
it is something to move towards if the ratio is close enough even if it
means denying some functionality to one group or the other until some
bugs are solved.
--
Daniel Ostrow
Gentoo Foundation Board of Trustees
Gentoo/{PPC,PPC64,DevRel}
[EMAIL PROTECTED]
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: [gentoo-core] crap use flags in the profiles
On 30/8/2005 10:46:54, Stephen P. Becker ([EMAIL PROTECTED]) wrote: Is this also a good time to note that the amd64 and x86 could *easily* be covered under the same keyword? The big reason I think, is that few x86 people have a clue about amd64. Contrast this with the mips team; I'd guess most mips devs understand the variations well enough. Thus it makes sense that amd64 should be able to keyword independently of x86. Kev. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: [gentoo-core] crap use flags in the profiles
Stephen P. Becker wrote: Shouldn't this fall under the x86 arch team rather than releng? The I'm sorry, but *what* x86 arch team? That's the point. Ciaran is just pointing out for the gazillionth time that x86 is an unsupported arch, if you go by the standards the other arches have to follow to be part of Gentoo. When is this going to be fixed? Or, will it just be ignored until all the x86 folks get amd64 machines and x86 pretty much becomes irrelevant? Is this also a good time to note that the amd64 and x86 could *easily* be covered under the same keyword? We cover a large variety of mips machines/userlands under one keyword, with differences much more significant then that between x86 and amd64. -Steve Any how many more x86 users are there than MIPS users to hit problems? How much worse is the QA in the x86/amd64 tree than the MIPS tree? I'm not trying to bash either team here, just pointing out the facts. Alec Warner (antarus) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: [gentoo-core] crap use flags in the profiles
On Tue, 2005-08-30 at 15:57 -0400, Alec Warner wrote: Stephen P. Becker wrote: Shouldn't this fall under the x86 arch team rather than releng? The I'm sorry, but *what* x86 arch team? That's the point. Ciaran is just pointing out for the gazillionth time that x86 is an unsupported arch, if you go by the standards the other arches have to follow to be part of Gentoo. When is this going to be fixed? Or, will it just be ignored until all the x86 folks get amd64 machines and x86 pretty much becomes irrelevant? Is this also a good time to note that the amd64 and x86 could *easily* be covered under the same keyword? We cover a large variety of mips machines/userlands under one keyword, with differences much more significant then that between x86 and amd64. -Steve Any how many more x86 users are there than MIPS users to hit problems? How much worse is the QA in the x86/amd64 tree than the MIPS tree? I'm not trying to bash either team here, just pointing out the facts. Alec Warner (antarus) I belive the worse QA is in x86 and not in AMD64 and MIPS. Between AMD64 and x86 there's a lot of differences i.e. many packages in the tree that needs to be patched to work on AMD64 so we cannot cover AMD64/x86 under the same keyword. During this time i belive that the AMD64 arch team is doing QA job for x86 arch too. Thanks to our Arch Testers we can test, patch and improve the quality of the packages for AMD64 and for x86 too. I Belive that MIPS team is doing the same thing they test packages then mark stable if the packages are really stable. -- Luis Medinas [EMAIL PROTECTED] http://dev.gentoo.org/~metalgod Gentoo Linux Developer: AMD64,Printing,app-cdr -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: [gentoo-core] crap use flags in the profiles
On Tue, 30 Aug 2005 21:15:18 + Luis Medinas [EMAIL PROTECTED] wrote: I belive the worse QA is in x86 and not in AMD64 and MIPS. Between AMD64 and x86 there's a lot of differences i.e. many packages in the tree that needs to be patched to work on AMD64 so we cannot cover AMD64/x86 under the same keyword. There are packages that will work on (for example) little-endian mips but won't work or will need patching to work on big-endian, yet we still cover both of those with one keyword. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: [gentoo-core] crap use flags in the profiles
On Tue, 2005-30-08 at 21:40 +0100, Stephen Bennett wrote: On Tue, 30 Aug 2005 21:15:18 + Luis Medinas [EMAIL PROTECTED] wrote: I belive the worse QA is in x86 and not in AMD64 and MIPS. Between AMD64 and x86 there's a lot of differences i.e. many packages in the tree that needs to be patched to work on AMD64 so we cannot cover AMD64/x86 under the same keyword. There are packages that will work on (for example) little-endian mips but won't work or will need patching to work on big-endian, yet we still cover both of those with one keyword. You are comparing apples and oranges.. Most of the herd devs only have x86 and are not able to test amd64. That's the main difference. And I dont think the QA is worst on x86.. Most herd devs are on x86 and its their responsability to do their QA. I've seen many horrible ebuilds done by ppc people too. And x86 has many more packages that any other architecture. Also, x86 is where most of the newbies are, we can't assume that if it works on amd64 it will also work on x86.. Let me say it again: x86 is still special.. its not a regular architecture. That said, I agree, we need an x86 team. Maybe you want to lead it ? -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer x86 Security Liaison -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: [gentoo-core] crap use flags in the profiles
On Tue, 30 Aug 2005 16:45:24 -0400 Olivier Crete [EMAIL PROTECTED] wrote: | And I dont think the QA is worst on x86.. Most herd devs are on x86 | and its their responsability to do their QA. QA needs coordination. Otherwise we end up with repeats of the Gnome not building on stable x86 for several weeks at a time because the Gnome and Mozilla herds don't talk to each other fiasco. | And x86 has many more packages that any other architecture. Careful with that... The difference is not so big as you might think, and when you consider how many people own, say, sparc and compare it with how many own x86, you might be surprised... -- Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm pgpNzDI908dMy.pgp Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-core] crap use flags in the profiles
On Tue, 2005-30-08 at 21:56 +0100, Ciaran McCreesh wrote: On Tue, 30 Aug 2005 16:45:24 -0400 Olivier Crete [EMAIL PROTECTED] wrote: | And I dont think the QA is worst on x86.. Most herd devs are on x86 | and its their responsability to do their QA. QA needs coordination. Otherwise we end up with repeats of the Gnome not building on stable x86 for several weeks at a time because the Gnome and Mozilla herds don't talk to each other fiasco. I could not agree more. Do you want to do the coordination ? | And x86 has many more packages that any other architecture. Careful with that... The difference is not so big as you might think, and when you consider how many people own, say, sparc and compare it with how many own x86, you might be surprised... Well, I would not be surprised at the number of packages that are not use by anyone on sparc or mips or even amd64. But that might have a few x86 users.. -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer x86 Security Liaison -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: [gentoo-core] crap use flags in the profiles
On Tue, 30 Aug 2005 17:16:09 -0400 Olivier Crete [EMAIL PROTECTED] wrote: | On Tue, 2005-30-08 at 21:56 +0100, Ciaran McCreesh wrote: | On Tue, 30 Aug 2005 16:45:24 -0400 Olivier Crete [EMAIL PROTECTED] | wrote: | | And I dont think the QA is worst on x86.. Most herd devs are on | | x86 and its their responsability to do their QA. | | QA needs coordination. Otherwise we end up with repeats of the | Gnome not building on stable x86 for several weeks at a time | because the Gnome and Mozilla herds don't talk to each other | fiasco. | | I could not agree more. Do you want to do the coordination ? If someone buys me a fast x86 box that will boot Linux, sure. -- Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm pgpdzA7wjzXXG.pgp Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-core] crap use flags in the profiles
On Tue, 30 Aug 2005 16:45:24 -0400 Olivier Crete [EMAIL PROTECTED] wrote: You are comparing apples and oranges.. Most of the herd devs only have x86 and are not able to test amd64. That's the main difference. Most of the mips devs only have 64-bit big endian SGI hardware, and aren't able to test on little-endian systems. Endianness issues are at least as big a problem as 64-bit issues when porting software. And I dont think the QA is worst on x86.. Most herd devs are on x86 and its their responsability to do their QA. I've seen many horrible ebuilds done by ppc people too. QA needs more than just the ebuilds not to suck. It needs someone making sure that the current stable versions of various packages play nicely together; see Ciaran's mail. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: [gentoo-core] crap use flags in the profiles
On Tue, 2005-08-30 at 16:45 -0400, Olivier Crete wrote: On Tue, 2005-30-08 at 21:40 +0100, Stephen Bennett wrote: On Tue, 30 Aug 2005 21:15:18 + Luis Medinas [EMAIL PROTECTED] wrote: I belive the worse QA is in x86 and not in AMD64 and MIPS. Between AMD64 and x86 there's a lot of differences i.e. many packages in the tree that needs to be patched to work on AMD64 so we cannot cover AMD64/x86 under the same keyword. There are packages that will work on (for example) little-endian mips but won't work or will need patching to work on big-endian, yet we still cover both of those with one keyword. You are comparing apples and oranges.. Most of the herd devs only have x86 and are not able to test amd64. That's the main difference. Yes you are right but we still need to take special treat for all archs not only for amd64 or x86. With AMD64 we have the resources to make a good QA. With x86 only the maintainers can take care of they own QA. Also, x86 is where most of the newbies are, we can't assume that if it works on amd64 it will also work on x86.. Let me say it again: x86 is still special.. its not a regular architecture. Sure every arch is special. But there are archs that needs more work then others i.e. MIPS That said, I agree, we need an x86 team. Maybe you want to lead it ? I agree too we need an x86 team. Any Senior Developer wants to take this position ? -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer x86 Security Liaison -- Luis Medinas [EMAIL PROTECTED] http://dev.gentoo.org/~metalgod Gentoo Linux Developer: AMD64,Printing,app-cdr -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: [gentoo-core] crap use flags in the profiles
On Wed, 2005-08-24 at 21:30 -0500, Kito wrote: So yeah, subprofiles, reasons why not? Aside from the work involved, I see no reason to not use the cascades for what they seem to be made for. As I understood it, they were implemented to reduce the amount of work necessary in maintaining them. As it was back then, it required changes to an extremely large number of profiles every time a change was made to the default USE flags. I honestly don't think it would be a good idea to forget the lessons of the past and start bloating the profiles with tons of desktop and server profiles, among anything else people would want. After all, as soon as we did a desktop profile, then we would have requests for gnome and kde sub-profiles. As I stated earlier, it's easier to not provide *any* than to try to provide all of the ones that will inevitably be requested as soon as we start adding them. -- Chris Gianelloni Release Engineering - Strategic Lead/QA Manager Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: [gentoo-core] crap use flags in the profiles
Chris Gianelloni wrote: On Wed, 2005-08-24 at 21:30 -0500, Kito wrote: So yeah, subprofiles, reasons why not? Aside from the work involved, I see no reason to not use the cascades for what they seem to be made for. As I understood it, they were implemented to reduce the amount of work necessary in maintaining them. As it was back then, it required changes to an extremely large number of profiles every time a change was made to the default USE flags. I honestly don't think it would be a good idea to forget the lessons of the past and start bloating the profiles with tons of desktop and server profiles, among anything else people would want. After all, as soon as we did a desktop profile, then we would have requests for gnome and kde sub-profiles. As I stated earlier, it's easier to not provide *any* than to try to provide all of the ones that will inevitably be requested as soon as we start adding them. In general, it sounds like a good idea, but as far as i can see, it would be a for-the-user and by-the-user idea, but what about for the devs, it doesn't look like something easy to mantain. Nevertheless, what if we can provide instead tools/docs to help users with the task?, so anyone willing to do it, could easily create his/her own sub-profiles for kde/gnome/whatever ... Just an idea :-] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: [gentoo-core] crap use flags in the profiles
On Sat, 2005-08-27 at 05:01 -0500, Brian Harring wrote: What I'm advocating is that the '05 profile (fex) tag in the defaults for that profile release, desktop/server agnostic, *system* defaults, eg toolchain, pam, nptl, etc. The subprofile the user chooses (the desktop or server target) building upon those base settngs. Multiple inherits for profiles is the main reason I'm not pushing on this; shifting desktop cruft out of the bases (my definition of base mind you) requires pulling from (fex) x86/2005.1 + desktop/2005.1 . Currently, the versioned profiles match what we use for building the release. The 2005.1 profile is the USE flags used to build the 2005.1 release. This makes complete sense to me and is the way it has been done in the past. Making the changes that you propose would require a 2005.1/desktop profile to be used for building GRP. The problem with this is it would also require that the same profile be used for building the stages. Basically, you've taken then 2005.1 profile and made it useless, since the stages weren't built against it anyway. 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? 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. -- Chris Gianelloni Release Engineering - Strategic Lead/QA Manager Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: [gentoo-core] crap use flags in the profiles
On Mon, 2005-08-29 at 11:59 -0400, Chris Gianelloni wrote: As I understood it, they were implemented to reduce the amount of work necessary in maintaining them. As it was back then, it required changes to an extremely large number of profiles every time a change was made to the default USE flags. Just a crazy idea - why not create a package containing some profiles? You can use the default profile, and if you want a different profile, emerge portage-profiles or whatever it is called and use that. I guess I've missed something obvious here? I honestly don't think it would be a good idea to forget the lessons of the past and start bloating the profiles with tons of desktop and server profiles, among anything else people would want. After all, as soon as we did a desktop profile, then we would have requests for gnome and kde sub-profiles. which are not much work if kde = desktop -gtk -gnome +kde As I stated earlier, it's easier to not provide *any* than to try to provide all of the ones that will inevitably be requested as soon as we start adding them. Or provide them in an extra ebuild that throws lots of warnings so that any users that don't read the warnings can be RESOLVED WONTFIXed? -- Stand still, and let the rest of the universe move signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: [gentoo-core] crap use flags in the profiles
If it was an extra ebuild, the profiles directory would need to exist outside of /usr/portage, would it not? This to prevent it from being blown up at next sync. On 8/29/05, Patrick Lauer [EMAIL PROTECTED] wrote: On Mon, 2005-08-29 at 11:59 -0400, Chris Gianelloni wrote: As I understood it, they were implemented to reduce the amount of work necessary in maintaining them. As it was back then, it required changes to an extremely large number of profiles every time a change was made to the default USE flags. Just a crazy idea - why not create a package containing some profiles? You can use the default profile, and if you want a different profile, emerge portage-profiles or whatever it is called and use that. I guess I've missed something obvious here? I honestly don't think it would be a good idea to forget the lessons of the past and start bloating the profiles with tons of desktop and server profiles, among anything else people would want. After all, as soon as we did a desktop profile, then we would have requests for gnome and kde sub-profiles. which are not much work if kde = desktop -gtk -gnome +kde As I stated earlier, it's easier to not provide *any* than to try to provide all of the ones that will inevitably be requested as soon as we start adding them. Or provide them in an extra ebuild that throws lots of warnings so that any users that don't read the warnings can be RESOLVED WONTFIXed? -- Stand still, and let the rest of the universe move -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2-ecc0.1.6 (GNU/Linux) iD8DBQBDE0+EqER3hOUoZM4RAoExAJ9vJH9lSOug5o8gVYljtNewLucYnwCcCgL5 uBwy5L+fKeOF2nw/YzyfjSM= =WwNl -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: [gentoo-core] crap use flags in the profiles
On Mon, 2005-08-29 at 20:10 +0200, Patrick Lauer wrote: On Mon, 2005-08-29 at 11:59 -0400, Chris Gianelloni wrote: As I understood it, they were implemented to reduce the amount of work necessary in maintaining them. As it was back then, it required changes to an extremely large number of profiles every time a change was made to the default USE flags. Just a crazy idea - why not create a package containing some profiles? You can use the default profile, and if you want a different profile, emerge portage-profiles or whatever it is called and use that. I guess I've missed something obvious here? How exactly would updating a ton of profiles, making a tarball of them, uploading the new tarball, waiting for it to hit the mirrors, then updating the ebuild in portage be easier to maintain than just maintaining the profiles directly in the tree? I honestly don't think it would be a good idea to forget the lessons of the past and start bloating the profiles with tons of desktop and server profiles, among anything else people would want. After all, as soon as we did a desktop profile, then we would have requests for gnome and kde sub-profiles. which are not much work if kde = desktop -gtk -gnome +kde Once there is multiple inheritance, I see this being easier. I still think it is going to be a waste of time for us to maintain them, however. Especially since *NO MEDIA* will be built against *any* of them except the default. As I stated earlier, it's easier to not provide *any* than to try to provide all of the ones that will inevitably be requested as soon as we start adding them. Or provide them in an extra ebuild that throws lots of warnings so that any users that don't read the warnings can be RESOLVED WONTFIXed? You're more than welcome to do this. *I* would just WONTFIX it anyway and not add *any* superfluous profiles just to appease some lazy users. The current profiles are built to be used *as is* for doing GRP installations. If the user doesn't like a flag or two, then they change it themselves. We don't need to get into the business of determining what should and should not be enabled on user's systems because we would *never* be able to make people happy. -- Chris Gianelloni Release Engineering - Strategic Lead/QA Manager Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: [gentoo-core] crap use flags in the profiles
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. Profiles aren't bound to the releases, despite how people may view it and/or the current profile maitnainer's usage of 'em. 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. 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. Aside from that, the comments about variations/minimal/not doing what you expect, what do you think USE=-* user's actual desired flags accomplishes? 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. 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. ~harring pgpnO9KjjXNG9.pgp Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-core] crap use flags in the profiles
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
Re: [gentoo-dev] Re: [gentoo-core] crap use flags in the profiles
On Mon, 2005-08-29 at 17:34 -0400, [EMAIL PROTECTED] wrote: I think Brian mentioned /etc/portage/profile and other fun portage tricks to mess with the default profile. If you think the profile shouldn't be changed then don't make it a mutable option. If you think that bugs where people fubared their profile are a problem then write a tool to print out that information and have the user present it to you when they file the bug. What? I was saying that *we* shouldn't have to waste *our* time making profiles we won't use. End of discussion. If you want a warner6-wuz-here profile under default-linux/x86 that turned off all the USE flags and only enabled USE=yes-I-really-only-want-this-one-USE then you could. We won't stop you, nor will we care to stop you. We wouldn't even complain. As far as maintainability, you could always make a profile outside of the default-linux tree ( default-gentoo/* ) and construct the smaller/faster/better profiles there. That means anyone that wants to No. *I* could not because *I* think it is a waste of time. I care about exactly one profile, in honesty, the one I use to build the release. If there were 10,000 other profiles, I wouldn't care. That being said, I wouldn't want anyone changing the profile I used to build the release. If I do a stage3 today and a stage3 tomorrow, both using the same profile, then do an emerge gnome on each, I would expect it to have the same USE flags. This is a simple matter of reproducibility and predictability. customize can change the symlink and you ( releng ) still get your pristine release profiles ( which IMHO is a silly notion, but I don't manage your bugs, so whichever way you like ;) ). Going on that notion, I am really shooting for predictability with the profiles that are managed by releng. you could also do default-linux/x86/2005.1/release or whatnot if you want to maintain that as well. Why? Would you not expect the 2005.1 Handbook plus the 2005.1 media plus the 2005.1 profile to produce a 2005.1 system? Why would I need a release sub-profile to distinguish it as a release? Is that not completely redundant? -- Chris Gianelloni Release Engineering - Strategic Lead/QA Manager Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: [gentoo-core] crap use flags in the profiles
On Mon, 29 Aug 2005 17:43:35 -0400 Chris Gianelloni [EMAIL PROTECTED] wrote: | 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. Shouldn't this fall under the x86 arch team rather than releng? The arch teams maintain the other profiles, and whilst the arch's releng contact will certainly be doing some of the changes, so will other arch team members who do not get deeply involved in the release process... -- Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: [gentoo-core] crap use flags in the profiles
On Mon, Aug 29, 2005 at 05:43:35PM -0400, Chris Gianelloni wrote: snip Re: not shoving work onto you, complicating your job, etc, I agree, and actually is what I was getting at in the badly worded section below 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? Basically stating that if I want the minimal 2005.1 x86 profile to build my own server profile off of, I can't really use the existing default-linux/x86/2005.1 ; Why? Mainly due to the fact that I would be forced to reverse a *lot* of stuff, use flags mainly, to get it back down to a minimal profile. That's what I mean by lack of customization; it can be done, but it's not optimal, vs say inheriting a base default/x86/2005.1 that holds just system defaults (pam, cflags, etc). If I were to implement a server profile from existing, I'd probably tag in -* to the use, and add the use flags I explicitly want; that's not really the best way to use the profiles inheritance capabilities though :) 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. Key thing to note, neither of us have figures :) Beyond that, I'm not after castrating the defaults that exist, I'm after sticking a level of indirection, a subprofile into the releng profile inheritance chain so that if I *want* a minimal profile (as you use), I can get it without having to resort to -* and tracking all of the changes myself. It's a time saving effort; add multiple inheritance in, and it's easy to do (win/win). 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. Agreed, although I'd posit that when/if multiple inheritance is added, y'all take advantage of it (break up the settings into base and desktop) so that others can use your base work instead of reinventing the wheel. ~harring pgpfFtin4sgb9.pgp Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-core] crap use flags in the profiles
Donnie Berkholz wrote: Brian Harring wrote: I don't recall having kde/gtk crap turned on by default when I first showed up. Maybe I'm missing something; regardless, the defaults (which should be minimal from my standpoint) are anything but. I think you recall wrong, then. The default USE flags have been set so that the majority of systems will work properly without modifications, not so that they're the minimal set. I agree with that, since it's easy to configure them, but the problem is that for most users, there is no default use flag at all. I'd say most of our users run either gtk (and gnome) or qt (and kde), but not both. Either you like gnome or kde ;) So we end up having qt, gtk, gtk2, gnome, kde and arts in the default use flags, but nearly nobody wants to use that, so I think it's better to have minimal use flags than pseudo-standard ones. Regards, -- Simon Stelling Gentoo/AMD64 Operational Co-Lead [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: [gentoo-core] crap use flags in the profiles
On Sun, 2005-08-28 at 12:01 +0200, Simon Stelling wrote: Donnie Berkholz wrote: Brian Harring wrote: I don't recall having kde/gtk crap turned on by default when I first showed up. Maybe I'm missing something; regardless, the defaults (which should be minimal from my standpoint) are anything but. I think you recall wrong, then. The default USE flags have been set so that the majority of systems will work properly without modifications, not so that they're the minimal set. I agree with that, since it's easy to configure them, but the problem is that for most users, there is no default use flag at all. I'd say most of our users run either gtk (and gnome) or qt (and kde), but not both. Either you like gnome or kde ;) So we end up having qt, gtk, gtk2, gnome, kde and arts in the default use flags, but nearly nobody wants to use that, so I think it's better to have minimal use flags than pseudo-standard ones. Regards, -- Simon Stelling Gentoo/AMD64 Operational Co-Lead [EMAIL PROTECTED] Hi, Think that at least some users have both GnomeKDE (i for example). All this because there are some apps which are QT/KDE based and others are GTK/Gnome based. Using 'k3b' which requires QT/KDElibs, also kdebase-startkde just to have a working DE. Have full Gnome, but most time work using XFCE4. Initially when configuring my USE-flags took the default ones and put them (commented in /etc/make.conf) to see them and switch some ON/OFF. Rumen -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: [gentoo-core] crap use flags in the profiles
On Thursday 25 August 2005 11:30, Kito wrote: On Aug 24, 2005, at 7:04 PM, Brian Harring wrote: So yeah, subprofiles, reasons why not? Aside from the work involved, I see no reason to not use the cascades for what they seem to be made for. Perhaps this is something that should wait for multiple-inheritance... Along with the work of getting it set up, there's also the inevitable mistakes that will be made in maintaining it. -- Jason Stubbs pgp5V6HDxsiON.pgp Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-core] crap use flags in the profiles
On Wednesday 24 August 2005 11:07 pm, Jason Stubbs wrote: On Thursday 25 August 2005 11:30, Kito wrote: On Aug 24, 2005, at 7:04 PM, Brian Harring wrote: So yeah, subprofiles, reasons why not? Aside from the work involved, I see no reason to not use the cascades for what they seem to be made for. Perhaps this is something that should wait for multiple-inheritance... Along with the work of getting it set up, there's also the inevitable mistakes that will be made in maintaining it. if we could declare multiple parents, that would make this a lot easier -mike -- gentoo-dev@gentoo.org mailing list
