[gentoo-dev] crap use flags in the profiles

[gentoo-dev] crap use flags in the profiles

[Brian Harring]

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

Hola all.

Out of curiousity, since for once my portage installation is *not* 
filtering out all flags but my own, I'm wondering why it is that the 
system default now holds a lot of use flags that aren't really related 
to the system set of packages.

See, from my standpoint cascaded profiles exist for the sake of being 
able to build up chunks, and merge them together.  If you want a 
desktop profile, hey, easy, just point it at the default, and import 
that.  If you want a server profile that doesn't have the crap 101 use 
flags that are defaulted, you just define a profile there.

The common point between the two being that you depend on a minimal, 
"this is the base profile" that is the common points, and overload 
what you need to in the specialized profile.  Iow, you jam all of the 
crap use flags into a desktop profile, rather then forcing people to 
do -*


So, fex, the following flags are rather desktop specific-
alsa 
arts 
avi 
bitmap-fonts 
cups 
eds
emboss (why the hell is "European Molecular Biology Open Software Suite"
  a profile default?  Seems extremely specialized)
encode 
fortran 
foomaticdb 
gnome 
gstreamer 
gtk 
gtk2 
imlib 
kde 
mad 
mikmod 
motif 
mp3 
mpeg 
ogg 
oggvorbis 
oss 
png 
qt 
quicktime 
sdl 
spell 
truetype 
truetype-fonts 
type1-fonts 
vorbis 
xml2 
xmms 

That's pretty much the entire list of flags in the defaults.

Again, returning to the USE="-*" arguement, yes, they can go that 
route.  It's also kind of a crappy arguement dodging out of the fact that 
progressive bloat going into what is effectively a base release 
profile, when subprofiles would be better suited.

You use the capabilities cascaded profiles give you, and you can serve 
both camps; those who want bloat, those who don't.

Question is why aren't we?  Yes work is required, but everything 
requires work- is there some stumbling block that makes the work 
involved excessive?

Personally, I run with -* not due to filtering out profile crap, but 
for filtering out autouse; I'm a bit disgusted by what the -* has been 
protecting me from.  In bug 93067, it's described that our default has 
always been to aim for desktop; well, depends on your definition of 
desktop.

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.

So... again.  What is holding us back from using existing capabilities 
to seperate this?  If it's not perfectly clean doing it, what do you 
require to make it easy/clean to do so?

Granted this phrase has been beat to fricking death, but we are about 
choice.  Again, yes, -* is a choice, it's also a rather nasty choice 
since the user must watch the profile's themselves and duplicate the 
use flags from there if they want the 'true' defaults.  That's shoving 
work off onto users when an alternative approach (subprofiles) could 
handle it globally.

So yeah, subprofiles, reasons why not?

My slightly flamey 2 cents
~harring

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

Re: [gentoo-dev] crap use flags in the profiles

[Mike Frysinger]

On Wednesday 24 August 2005 08:04 pm, Brian Harring wrote:
> Again, returning to the USE="-*" arguement, yes, they can go that
> route.  It's also kind of a crappy arguement dodging out of the fact that
> progressive bloat going into what is effectively a base release
> profile, when subprofiles would be better suited.

not sure what you mean by 'progressive bloat' ... most of those flags have 
been there since before i was a dev (so like before the 1.2 release)

the default profile has always been a 'desktop' target and really i think 
that's OK by me
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] crap use flags in the profiles

[Brian Harring]

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

On Wed, Aug 24, 2005 at 08:50:58PM -0400, Mike Frysinger wrote:
> On Wednesday 24 August 2005 08:04 pm, Brian Harring wrote:
> > Again, returning to the USE="-*" arguement, yes, they can go that
> > route.  It's also kind of a crappy arguement dodging out of the fact that
> > progressive bloat going into what is effectively a base release
> > profile, when subprofiles would be better suited.
> 
> not sure what you mean by 'progressive bloat' ... most of those flags have 
> been there since before i was a dev (so like before the 1.2 release)
> 
> the default profile has always been a 'desktop' target and really i think 
> that's OK by me
Reasons against sticking a level of indirection in?
More then willing to assume I've been a tool and missed it, but with 
cascaded profiles there really isn't a good arguement against tagging 
a level in so that anyone after it can just use minimal, or derive a 
server profile off of it.
~harring

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

[gentoo-dev] Re: [gentoo-core] crap use flags in the profiles

[Kito]

On Aug 24, 2005, at 7:04 PM, Brian Harring wrote:

> Hola all.
>

[...]

>
> So, fex, the following flags are rather desktop specific-
> alsa
> arts
> avi
> bitmap-fonts
> cups
> eds
> emboss (why the hell is "European Molecular Biology Open Software  
> Suite"
>   a profile default?  Seems extremely specialized)
> encode
> fortran
> foomaticdb
> gnome
> gstreamer
> gtk
> gtk2
> imlib
> kde
> mad
> mikmod
> motif
> mp3
> mpeg
> ogg
> oggvorbis
> oss
> png
> qt
> quicktime
> sdl
> spell
> truetype
> truetype-fonts
> type1-fonts
> vorbis
> xml2
> xmms
>

When I did my first Gentoo install in the 1.4ish era, I was pretty  
shocked to see roughly this same insane list. I quickly learned about  
the -* trick, as the main thing that brought me to this distro was  
the minimalist factor. As you pointed out, -* is pretty ugly as it  
leaves the user with the task of recreating a sane default use list.

[...]

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


--Kito

>
> My slightly flamey 2 cents
> ~harring

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: [gentoo-core] crap use flags in the profiles

[Jason Stubbs]

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

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

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

Re: [gentoo-dev] crap use flags in the profiles

[Lance Albertson]

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

Brian Harring wrote:
> On Wed, Aug 24, 2005 at 08:50:58PM -0400, Mike Frysinger wrote:
> 
>>On Wednesday 24 August 2005 08:04 pm, Brian Harring wrote:
>>
>>>Again, returning to the USE="-*" arguement, yes, they can go that
>>>route.  It's also kind of a crappy arguement dodging out of the fact that
>>>progressive bloat going into what is effectively a base release
>>>profile, when subprofiles would be better suited.
>>
>>not sure what you mean by 'progressive bloat' ... most of those flags have 
>>been there since before i was a dev (so like before the 1.2 release)
>>
>>the default profile has always been a 'desktop' target and really i think 
>>that's OK by me
> 
> Reasons against sticking a level of indirection in?
> More then willing to assume I've been a tool and missed it, but with 
> cascaded profiles there really isn't a good arguement against tagging 
> a level in so that anyone after it can just use minimal, or derive a 
> server profile off of it.

Generally the hardened profile has been considered the most 'server'
based profile we have. Granted, if you don't want the extra goodies you
get with a hardened system, that is an issue, but this is one option we
have. I look at their profile as a great model for the server end of things.

-- 
Lance Albertson <ramereth@gentoo.org>
Gentoo Infrastructure | Operations Manager

---
GPG Public Key:  <http://www.ramereth.net/lance.asc>
Key fingerprint: 0423 92F3 544A 1282 5AB1  4D07 416F A15D 27F4 B742

ramereth/irc.freenode.net

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] crap use flags in the profiles

[Mike Frysinger]

On Wednesday 24 August 2005 09:27 pm, Brian Harring wrote:
> On Wed, Aug 24, 2005 at 08:50:58PM -0400, Mike Frysinger wrote:
> > On Wednesday 24 August 2005 08:04 pm, Brian Harring wrote:
> > > Again, returning to the USE="-*" arguement, yes, they can go that
> > > route.  It's also kind of a crappy arguement dodging out of the fact
> > > that progressive bloat going into what is effectively a base release
> > > profile, when subprofiles would be better suited.
> >
> > not sure what you mean by 'progressive bloat' ... most of those flags
> > have been there since before i was a dev (so like before the 1.2 release)
> >
> > the default profile has always been a 'desktop' target and really i think
> > that's OK by me
>
> Reasons against sticking a level of indirection in?
> More then willing to assume I've been a tool and missed it, but with
> cascaded profiles there really isn't a good arguement against tagging
> a level in so that anyone after it can just use minimal, or derive a
> server profile off of it.

not quite sure what you're talking about ... the 'USE bloat' only exists in 
subprofiles

- base doesnt define any USE
- default-linux defines a few local xorg USE (because no one has given us the 
ability to control default USE via IUSE yet :P)

{x86,amd64}/make.defaults has the 'bloated' USE because every single sub x86 
and amd64 profile had the same USE in them ... if you want to re-push them 
into subprofiles like 200[45].[01], that's fine by me ... will have to check 
with wolf/releng so they dont revert it :P
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: [gentoo-core] crap use flags in the profiles

[Mike Frysinger]

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

[gentoo-dev] Re: [gentoo-core] crap use flags in the profiles

[Donnie Berkholz]

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.

The purpose of being able to negate USE flags in lower cascaded profiles 
is pointless if each level is the minimum. I think it makes more sense 
to have each level be a reasonable default that most people would 
prefer, then have weird exceptions subtract it.

Donnie
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: [gentoo-core] crap use flags in the profiles

[Brian Harring]

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

Note, sending to dev only, not cc'ing core; the inital -core post was 
to make sure those who aren't watching dev ml see the email (annoying, 
but it's an old habit I've yet to kick despite needing to).

On Sat, Aug 27, 2005 at 04:48:26AM -0500, 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.
Already stated that it's entirely possible my memory is whacked, that 
said my point still stands.

> The purpose of being able to negate USE flags in lower cascaded profiles 
> is pointless if each level is the minimum. I think it makes more sense 
> to have each level be a reasonable default that most people would 
> prefer, then have weird exceptions subtract it.

Note I'm not advocating every level of the profile be bare minimal, 
with the end nodes having tons jammed into it; I'm advocating exactly 
what you're stating.  Chunk the sucker up, shifting stuff around just 
the same as you would if you were designing base classes to be 
inherited.

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.

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 .

My 2 cents at least.
~harring

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

Re: [gentoo-dev] Re: [gentoo-core] crap use flags in the profiles

[Simon Stelling]

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
blubb@gentoo.org
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: [gentoo-core] crap use flags in the profiles

[Rumen Yotov]

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
> blubb@gentoo.org
Hi,
Think that at least some users have both Gnome&KDE (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] crap use flags in the profiles

[Chris Gianelloni]

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

On Thu, 2005-08-25 at 00:28 -0400, Mike Frysinger wrote:
> - base doesnt define any USE
> - default-linux defines a few local xorg USE (because no one has given us the 
> ability to control default USE via IUSE yet :P)
> 
> {x86,amd64}/make.defaults has the 'bloated' USE because every single sub x86 
> and amd64 profile had the same USE in them ... if you want to re-push them 
> into subprofiles like 200[45].[01], that's fine by me ... will have to check 
> with wolf/releng so they dont revert it :P

I moved them from the sub-profiles since they were redundant.

As for the profiles... the versioned profiles that you see are the ones
used by releng for each architecture to build the release.  This means
they have all of the USE flags that we want enabled for the release.
While we could create a smaller set of USE flags for the "x86" (and
amd64) profiles, then only add the huge USE list to the versioned
profiles, it wouldn't make a bit of difference, since everything we have
everywhere points the users to the versioned profiles anyway.
Basically, it would add more work for whomever maintains the profiles,
and our users wouldn't gain anything from it.  Currently, there is
nothing stopping anyone from creating a "server" sub-profile that only
had a minimal set of USE flags.  The reason why there isn't any is
because nobody is taking the time and energy to do it.  Basically, the
capability is there, but with nobody actually doing it, it tells me that
the demand isn't there.

The other thing is that any profile that shows up in the tree under
default-linux ends up being releng's responsibility, for the most part.
Can't users define their own profiles?  Why do we need to make one
ourselves?  Our profiles are "defaults", not meant to be the end-all
be-all of USE flag selection.

We've actually been talking about making the profiles more like this,
but really need to weigh the additional work required to validate them
before we go deciding that we're going to start adding profiles for
specific uses.  I tend to believe that if we start adding them, we'll
soon be bombarded with "I want a $x profile because I don't like this
one USE flag" kind of bugs.  It's much easier to say "this is our
defaults, change them as you like" than it is to provide multiple sets
of "defaults" all of which are completely arbitrary.

It would also increase the amount of work that needs to be done when the
defaults do need to be changed.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead/QA Manager
Games - Developer
Gentoo Linux

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

Re: [gentoo-dev] Re: [gentoo-core] crap use flags in the profiles

[Chris Gianelloni]

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

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

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

Re: [gentoo-dev] crap use flags in the profiles

[Luis F. Araujo]

Chris Gianelloni wrote:

>On Thu, 2005-08-25 at 00:28 -0400, Mike Frysinger wrote:
>  
>
>>- base doesnt define any USE
>>- default-linux defines a few local xorg USE (because no one has given us the 
>>ability to control default USE via IUSE yet :P)
>>
>>{x86,amd64}/make.defaults has the 'bloated' USE because every single sub x86 
>>and amd64 profile had the same USE in them ... if you want to re-push them 
>>into subprofiles like 200[45].[01], that's fine by me ... will have to check 
>>with wolf/releng so they dont revert it :P
>>    
>>
>
>
>We've actually been talking about making the profiles more like this,
>but really need to weigh the additional work required to validate them
>before we go deciding that we're going to start adding profiles for
>specific uses.  I tend to believe that if we start adding them, we'll
>soon be bombarded with "I want a $x profile because I don't like this
>one USE flag" kind of bugs.  It's much easier to say "this is our
>defaults, change them as you like" than it is to provide multiple sets
>of "defaults" all of which are completely arbitrary.
>
>  
>
That's for sure that will happen. I also agree with keeping a default
and letting the users build their own profiles out of it.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: [gentoo-core] crap use flags in the profiles

[Luis F. Araujo]

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

[Chris Gianelloni]

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

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

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

Re[2]: [gentoo-dev] Re: [gentoo-core] crap use flags in the profiles

[Jakub Moc]

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


29.8.2005, 17:59:07, Chris Gianelloni wrote:

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

Uhm, we don't need desktop profile, the current profiles are desktop ones - a
pretty bloated desktop, but whatever... I'd really welcome server profile
though, basically w/ the set of USE flags that hardened profile provides, but
without hardened features.


-- 
Best regards,

 Jakub Moc
 mailto:jakub@gentoo.org
 GPG signature: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature ;)

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

Re: [gentoo-dev] Re: [gentoo-core] crap use flags in the profiles

[Patrick Lauer]

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

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

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

Re: [gentoo-dev] Re: [gentoo-core] crap use flags in the profiles

[Dan Meltzer]

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 <patrick@gentoo.org> 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

[Chris Gianelloni]

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

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

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

Re: [gentoo-dev] Re: [gentoo-core] crap use flags in the profiles

[Brian Harring]

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

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

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

Re: [gentoo-dev] Re: [gentoo-core] crap use flags in the profiles

[warnera6]

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

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
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,
you could also do default-linux/x86/2005.1/release or whatnot if you want
to maintain that as well.

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: [gentoo-core] crap use flags in the profiles

[Chris Gianelloni]

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

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

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

Re: [gentoo-dev] Re: [gentoo-core] crap use flags in the profiles

[Chris Gianelloni]

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

On Mon, 2005-08-29 at 17:34 -0400, warnera6@egr.msu.edu 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

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

Re: [gentoo-dev] Re: [gentoo-core] crap use flags in the profiles

[Ciaran McCreesh]

On Mon, 29 Aug 2005 17:43:35 -0400 Chris Gianelloni
<wolf31o2@gentoo.org> 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

[Brian Harring]

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

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

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

Re: [gentoo-dev] Re: [gentoo-core] crap use flags in the profiles

[Alec Warner]

Chris Gianelloni wrote:

>On Mon, 2005-08-29 at 17:34 -0400, warnera6@egr.msu.edu 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.
>
>  
>
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.

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

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 
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 ;)

-Alec Warner (antarus)


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: [gentoo-core] crap use flags in the profiles

[Luis F. Araujo]

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

[Chris Gianelloni]

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

On Mon, 2005-08-29 at 23:12 +0100, Ciaran McCreesh wrote:
> On Mon, 29 Aug 2005 17:43:35 -0400 Chris Gianelloni
> <wolf31o2@gentoo.org> 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

I'm sorry, but *what* x86 arch team?

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

Nothing is stopping them from making changes.  At the same time, I bet
they also talk with their releng contact when they make the changes to
make sure it won't completely hose something up.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead/QA Manager
Games - Developer
Gentoo Linux

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

Re: [gentoo-dev] Re: [gentoo-core] crap use flags in the profiles

[Chris Gianelloni]

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

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

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

Re: [gentoo-dev] Re: [gentoo-core] crap use flags in the profiles

[Chris Gianelloni]

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

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

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

Re: [gentoo-dev] Re: [gentoo-core] crap use flags in the profiles

[Stephen P. Becker]

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

[Francesco R]

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

[Stephen P. Becker]

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

[Olivier Crete]

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
tester@gentoo.org
Gentoo Developer
x86 Security Liaison


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: [gentoo-core] crap use flags in the profiles

[Chris Gianelloni]

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

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

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

Re: [gentoo-dev] Re: [gentoo-core] crap use flags in the profiles

[Francesco R]

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

[Stephen Bennett]

On Tue, 30 Aug 2005 17:46:20 +0200
Francesco R <vivo@gentoo.org> 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

[Daniel Ostrow]

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}
dostrow@gentoo.org

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: [gentoo-core] crap use flags in the profiles

[Kevin F. Quinn]

On 30/8/2005 10:46:54, Stephen P. Becker (geoman@gentoo.org) 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

[Alec Warner]

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

[Stephen Bennett]

On Tue, 30 Aug 2005 21:15:18 +0000
Luis Medinas <metalgod@gentoo.org> 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

[Olivier Crete]

On Tue, 2005-30-08 at 21:40 +0100, Stephen Bennett wrote:
> On Tue, 30 Aug 2005 21:15:18 +0000
> Luis Medinas <metalgod@gentoo.org> 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
tester@gentoo.org
Gentoo Developer
x86 Security Liaison


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: [gentoo-core] crap use flags in the profiles

[Ciaran McCreesh]

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

On Tue, 30 Aug 2005 16:45:24 -0400 Olivier Crete <tester@gentoo.org>
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


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

Re: [gentoo-dev] Re: [gentoo-core] crap use flags in the profiles

[Luis Medinas]

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 <metalgod@gentoo.org>
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

[Olivier Crete]

On Tue, 2005-30-08 at 21:56 +0100, Ciaran McCreesh wrote:
> On Tue, 30 Aug 2005 16:45:24 -0400 Olivier Crete <tester@gentoo.org>
> 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
tester@gentoo.org
Gentoo Developer
x86 Security Liaison


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: [gentoo-core] crap use flags in the profiles

[Ciaran McCreesh]

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

On Tue, 30 Aug 2005 17:16:09 -0400 Olivier Crete <tester@gentoo.org>
wrote:
| On Tue, 2005-30-08 at 21:56 +0100, Ciaran McCreesh wrote:
| > On Tue, 30 Aug 2005 16:45:24 -0400 Olivier Crete <tester@gentoo.org>
| > 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


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

Re: [gentoo-dev] Re: [gentoo-core] crap use flags in the profiles

[Stephen Bennett]

On Tue, 30 Aug 2005 16:45:24 -0400
Olivier Crete <tester@gentoo.org> 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

[Luis Medinas]

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 +0000
> > Luis Medinas <metalgod@gentoo.org> 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
> tester@gentoo.org
> Gentoo Developer
> x86 Security Liaison
> 
> 
-- 
Luis Medinas <metalgod@gentoo.org>
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

[Paul de Vrieze]

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

On Tuesday 30 August 2005 23:36, Stephen Bennett wrote:
> On Tue, 30 Aug 2005 16:45:24 -0400
>
> Olivier Crete <tester@gentoo.org> 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: pauldv@gentoo.org
Homepage: http://www.devrieze.net

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

[gentoo-dev] Re: Re: [gentoo-core] crap use flags in the profiles

[Duncan]

Stephen Bennett posted <20050830214002.1ce72cc2@localhost>, excerpted
below,  on Tue, 30 Aug 2005 21:40:02 +0100:

> On Tue, 30 Aug 2005 21:15:18 +0000
> Luis Medinas <metalgod@gentoo.org> 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.

OK, I've seen this mentioned several times, but never with an explanation
of how to do it, without either causing issues for the one segment, or
holding up keywording perfectly working packages on another segment. 
Perhaps it can be done, please explain how if so.

No offense intended, but as a user, I /like/ to actually know that a
package keyworded for my arch (segment) is known to work on it in full
(IMHO) uncrippled amd64 form, not in some (IMHO) "crippled 32-bit special
case". If we went the other way and removed x86 keywording from everything
that failed in 64-bit mode, including all 32-bit only codecs and the like,
x86(32) arch(segment) folks would rightly be wailing in protest.

Again, no offense intended, but unless you have some magic way to fix that
situation, perhaps the MIPS devs and users are willing to live with that
problem on MIPS, but neither x86(32) users nor amd64 users (and by this
I'm including devs, which are obviously users as well) are interested in
being saddled with an unnecessary problem, when the current situation
avoids it, or I expect the amd64 keyword would have never been added.

-- 
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 in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: [gentoo-core] crap use flags in the profiles

[Stephen P. Becker]

> OK, I've seen this mentioned several times, but never with an explanation
> of how to do it, without either causing issues for the one segment, or
> holding up keywording perfectly working packages on another segment. 
> Perhaps it can be done, please explain how if so.

Keep in mind that the *stable* trees of x86 and amd64 are actually 
pretty close to the same versions anyway, I just ran gmsoft's imlate 
script for amd64 vs. x86 keywords:

Package Name                            amd64               x86
--------------------------------------------------------------------------------
app-accessibility/gnome-speech          0.3.6               0.3.7-r1
app-accessibility/gok                   1.0.3               1.0.5
app-accessibility/java-access-bridge    1.4.2               1.4.5-r1
app-arch/arj                            3.10.21             3.10g
app-crypt/gringotts                     1.2.8               1.2.8-r1
app-doc/quanta-docs                     20030405            20041123
app-editors/gedit                       2.10.3              2.10.3-r1
app-editors/kile                        1.7.1               1.8.1-r1
app-editors/mlview                      0.6.3               0.8
app-emacs/nxml-mode                     20040910            20041004
app-emulation/spim                      6.5-r1              7.0
app-i18n/im-ja                          1.3-r1              1.4
app-i18n/koffice-i18n                   1.3.5               1.4.1
app-i18n/manpages-es                    1.28                1.55
app-i18n/scim                           1.2.2               1.4.1
app-i18n/skk-jisyo-cdb                  200410              200504
app-i18n/uim                            0.4.5.1             0.4.7.1-r2
app-laptop/tpctl                        4.8                 4.16
app-misc/jitac                          0.2.0               0.2.0-r1
app-misc/mime-types                     2                   3
app-misc/muttprint                      0.72a               0.72d
app-office/koffice                      1.3.5-r2            1.4.1
app-portage/splat                       0.07                0.08
app-shells/zsh                          4.2.4               4.2.5
app-text/convmv                         1.05                1.08
app-text/docbook-dsssl-stylesheets      1.77-r2             1.79
app-text/docbook-sgml-dtd               4.2-r2              4.4
app-text/docbook-sgml-utils             0.6.12              0.6.14
app-text/docbook-xml-dtd                4.3                 4.4
app-text/docbook-xml-simple-dtd         4.1.2.4             4.1.2.4-r2
app-text/docbook-xsl-stylesheets        1.66.1              1.68.1-r1
app-text/enchant                        1.1.5               1.1.6
app-text/epstool                        3.06                3.08
app-text/estraier                       1.2.25              1.2.26
app-text/gnome-doc-utils                0.2.0               0.2.1
app-text/gnome-spell                    1.0.5-r2            1.0.6
app-text/hd2u                           0.9.2               1.0.0
app-text/libwpd                         0.7.1               0.7.2
app-text/sablotron                      1.0                 1.0.1
app-text/scrollkeeper                   0.3.14              0.3.14-r1
dev-cpp/libxmlpp                        2.8.0-r2            2.10.0-r1
dev-db/pgpool                           2.5.2               2.6.2
dev-db/pygresql                         3.6.1               3.6.2
dev-db/qdbm                             1.8.17              1.8.30
dev-db/rekall                           2.2.3-r1            2.2.4
dev-db/unixODBC                         2.2.6               2.2.11-r1
dev-java/adaptx                         0.9.13_p20041105 
0.9.13_p20041105-r1
dev-java/cryptix-jce-bin                20030217            20040825
dev-java/ecs                            1.4.1-r1            1.4.2
dev-java/edtftpj                        1.4.4               1.4.8
dev-java/fscript                        1.14                1.15
dev-java/gnu-jaxp                       1.0_beta1-r1        1.3
dev-java/gnu-regexp                     1.1.4               1.1.4-r1
dev-java/itext                          1.2.3               1.3
dev-java/javolution                     2.2.0               3.2.4
dev-java/jcommon                        0.9.7               0.9.7-r1
dev-java/jdbc-mysql                     3.0.16              3.0.17
dev-java/jdbc2-postgresql               7.3                 7.4
dev-java/jdom                           1.0_beta10-r3       1.0
dev-java/jmp                            0.46                0.47
dev-java/jscience                       1.0.3               1.0.4
dev-java/lucene                         1.4.1               1.4.3
dev-java/mockobjects                    0.09                0.09-r1
dev-java/rhino                          1.5.5-r1            1.6.1-r1
dev-java/saxon-bin                      8.0b                8.4b
dev-java/xdoclet                        1.2.1               1.2.2
dev-libs/atk                            1.9.1               1.10.1
dev-libs/bglibs                         1.017               1.019-r1
dev-libs/dbh                            1.0.20              1.0.24
dev-libs/dietlibc                       0.25                0.28
dev-libs/dvacm4                         0.3.5               0.3.5-r1
dev-libs/glib                           2.6.4               2.6.5
dev-libs/http-fetcher                   1.0.3               1.1.0
dev-libs/libdaemon                      0.7                 0.8
dev-libs/libksba                        0.4.7               0.9.11
dev-libs/libpqxx                        2.4.2               2.5.1
dev-libs/libxslt                        1.1.14              1.1.14-r2
dev-libs/openobex                       1.0.0               1.0.1
dev-libs/xerces-c                       2.6.0               2.6.0-r1
dev-libs/yaz                            2.0.8               2.1.8-r1
dev-perl/Apache-Test                    1.15                1.23
dev-perl/AppConfig                      1.56-r1             1.56-r2
dev-perl/Authen-SASL                    2.04                2.09
dev-perl/Class-Autouse                  1.12                1.17
dev-perl/Class-Default                  1.0                 1.1
dev-perl/Crypt-OpenSSL-RSA              0.19                0.21
dev-perl/Crypt-SSLeay                   0.49                0.51
dev-perl/DBD-Pg                         1.22                1.43
dev-perl/Devel-StackTrace               1.03                1.11
dev-perl/Digest-MD4                     1.3                 1.5
dev-perl/Digest-SHA1                    2.07                2.10
dev-perl/Exception-Class                1.14-r1             1.21
dev-perl/ExtUtils-CBuilder              0.05                0.12
dev-perl/Filter                         1.29                1.30
dev-perl/GD                             2.18                2.23
dev-perl/HTML-LinkExtractor             0.12.1              0.13
dev-perl/HTML-Parser                    3.36-r1             3.45
dev-perl/HTML-Template                  2.6-r1              2.7
dev-perl/HTML-Tree                      3.17                3.18
dev-perl/Locale-PO                      0.12                0.14
dev-perl/Net-DNS                        0.48                0.49
dev-perl/Net-RawIP                      0.1                 0.2
dev-perl/POE                            0.26                0.30.09
dev-perl/Params-Validate                0.72                0.76
dev-perl/Template-Toolkit               2.09                2.14
dev-perl/WWW-Mechanize                  1.04                1.12
dev-perl/XML-DT                         0.32                0.37
dev-perl/XML-LibXSLT                    1.53                1.57
dev-perl/XML-Sablot                     0.90-r1             0.98
dev-perl/XML-Twig                       3.15-r1             3.17
dev-perl/crypt-random                   1.13                1.25
dev-perl/gnome2-wnck                    0.04-r1             0.10
dev-perl/gtk-perl                       0.7008-r11          0.7009-r2
dev-perl/libintl-perl                   1.10                1.11
dev-perl/libxml-perl                    0.07-r2             0.08
dev-perl/log-dispatch                   2.08                2.10
dev-perl/math-pari                      2.010500-r1         2.010603
dev-perl/perl-ldap                      0.31                0.33
dev-php/PECL-apc                        2.0.4               3.0.6
dev-php/adodb                           4.55                4.64
dev-python/docutils                     0.3.3-r1            0.3.5
dev-python/fpconst                      0.6.0               0.7.1
dev-python/geoip-python                 0.2.0               1.2.0
dev-python/gnuplot-py                   1.6                 1.7
dev-python/logilab-common               0.5.0               0.9.3
dev-python/mysql-python                 1.0.0               1.2.0
dev-python/pycrypto                     1.9_alpha6          2.0-r1
dev-python/pycurl                       7.13.1              7.13.2
dev-python/pygame                       1.6                 1.6.2
dev-python/pysqlite                     0.5.1               1.0.1
dev-python/wxpython                     2.4.2.4             2.4.2.4-r2
dev-ruby/ruby-opengl                    0.32c               0.32d
dev-util/desktop-file-utils             0.9                 0.10
dev-util/devhelp                        0.9.3               0.10
dev-util/gob                            2.0.9               2.0.12
dev-util/intltool                       0.31.2              0.33
dev-util/kdevelop                       3.1.2               3.2.1-r1
dev-util/libconf                        0.39.21             0.40.00
dev-util/monotone                       0.18                0.19
dev-util/source-highlight               1.11-r2             2.0
games-board/crafty                      19.8                19.20
games-emulation/xmame                   0.83.1              0.99-r1
games-emulation/xmess                   0.83.1              0.99-r1
games-util/qstat                        2.7                 2.8
games-util/xqf                          1.0.2               1.0.3
gnome-base/control-center               2.10.1-r1           2.10.2
gnome-base/gail                         1.8.3               1.8.4
gnome-base/gconf                        2.10.0              2.10.1-r1
gnome-base/gdm                          2.6.0.9-r2          2.8.0.1-r1
gnome-base/gnome                        2.10.1              2.10.2
gnome-base/gnome-desktop                2.10.1              2.10.2
gnome-base/gnome-keyring                0.4.2               0.4.3
gnome-base/gnome-menus                  2.10.1              2.10.2-r1
gnome-base/gnome-session                2.10.0              2.10.0-r3
gnome-base/gnome-volume-manager         1.2.1               1.2.2
gnome-base/libbonobo                    2.8.1               2.10.0
gnome-base/libbonoboui                  2.8.1               2.10.0
gnome-base/libgnome                     2.10.0              2.10.1-r1
gnome-base/libgnomecanvas               2.10.0              2.10.2
gnome-base/libgnomeui                   2.10.0              2.10.1
gnome-base/libgtop                      2.10.1              2.10.2
gnome-extra/at-spi                      1.6.3               1.6.4
gnome-extra/libgda                      1.0.3               1.2.2
gnome-extra/libgnomedb                  1.0.4               1.2.2
gnome-extra/libgsf                      1.12.0              1.12.1
gnome-extra/nautilus-cd-burner          2.10.1              2.10.2
gnustep-base/gnustep-back-art           0.9.4-r1            0.9.5
gnustep-base/gnustep-base               1.10.1-r1           1.10.3
gnustep-base/gnustep-env                0.1.5               0.1.6-r1
gnustep-base/gnustep-gui                0.9.4               0.9.5
mail-filter/amavisd-new                 2.2.1-r2            2.3.2
mail-filter/razor                       2.74                2.77
media-fonts/ttf-bitstream-vera          1.10-r2             1.10-r3
media-gfx/gimp                          2.2.6-r1            2.2.8-r1
media-gfx/gphoto2                       2.1.4               2.1.5
media-gfx/graphviz                      1.10                1.16
media-gfx/gthumb                        2.6.3               2.6.5
media-gfx/kst                           0.97                1.1.0
media-gfx/splashutils                   1.1.9.7             1.1.9.8
media-libs/adplug                       1.5                 1.5.1
media-libs/compface                     1.4                 1.5.1
media-libs/gst-plugins                  0.8.8-r2            0.8.10
media-libs/gstreamer                    0.8.9-r3            0.8.10
media-libs/libmng                       1.0.5               1.0.8-r1
media-libs/libnjb                       1.2                 2.2
media-plugins/gst-plugins-a52dec        0.8.8               0.8.10
media-plugins/gst-plugins-alsa          0.8.8               0.8.10
media-plugins/gst-plugins-cdparanoia    0.8.8               0.8.10
media-plugins/gst-plugins-dv            0.8.8               0.8.10
media-plugins/gst-plugins-dvdread       0.8.8               0.8.10
media-plugins/gst-plugins-esd           0.8.8               0.8.10
media-plugins/gst-plugins-faac          0.8.8               0.8.10
media-plugins/gst-plugins-faad          0.8.8               0.8.10
media-plugins/gst-plugins-flac          0.8.8               0.8.10
media-plugins/gst-plugins-gnomevfs      0.8.8               0.8.10
media-plugins/gst-plugins-jpeg          0.8.8               0.8.10
media-plugins/gst-plugins-lame          0.8.8               0.8.10
media-plugins/gst-plugins-libpng        0.8.8-r1            0.8.10
media-plugins/gst-plugins-mad           0.8.8               0.8.10
media-plugins/gst-plugins-mpeg2dec      0.8.8               0.8.10
media-plugins/gst-plugins-ogg           0.8.8               0.8.10
media-plugins/gst-plugins-oss           0.8.8               0.8.10
media-plugins/gst-plugins-pango         0.8.8-r1            0.8.10
media-plugins/gst-plugins-raw1394       0.8.8               0.8.10
media-plugins/gst-plugins-shout2        0.8.8               0.8.10
media-plugins/gst-plugins-speex         0.8.8               0.8.10
media-plugins/gst-plugins-theora        0.8.8               0.8.10
media-plugins/gst-plugins-v4l           0.8.8               0.8.10
media-plugins/gst-plugins-vorbis        0.8.8               0.8.10
media-plugins/gst-plugins-xvideo        0.8.8               0.8.10
media-sound/edna                        0.5-r3              0.5-r4
media-sound/esound                      0.2.34              0.2.36-r1
media-sound/gnomad                      2.5.0               2.8.0
media-sound/musepack-tools              1.15u               1.15v
media-tv/tvtime                         0.9.12              0.9.15
media-tv/xmltv                          0.5.34              0.5.37-r1
media-video/totem                       1.0.2-r1            1.0.4
net-analyzer/rrdtool                    1.0.49              1.2.6-r1
net-dialup/cutecom                      0.12.0              0.13.1
net-dialup/ppp                          2.4.2-r10           2.4.2-r12
net-dns/pdnsd                           1.1.10              1.2.2
net-im/micq                             0.5.0.1             0.5.0.3
net-im/silc-toolkit                     0.9.12-r3           1.0
net-im/sim                              0.8.3               0.9.3-r2
net-libs/libsoup                        2.2.3               2.2.3-r1
net-libs/wvstreams                      4.0.1-r2            4.0.2
net-mail/getmail                        4.3.6               4.3.11
net-mail/gotmail                        0.8.2-r1            0.8.4
net-misc/bridge-utils                   1.0.6-r2            1.0.6-r3
net-misc/putty                          0.57                0.58
net-misc/tightvnc                       1.2.9-r1            1.3_alpha5
net-nds/jxplorer                        3.1_rc4             3.1
net-wireless/irda-utils                 0.9.16              0.9.16-r1
perl-core/ExtUtils-MakeMaker            6.20                6.21
perl-core/File-Spec                     0.87                3.06
perl-core/digest-base                   1.05                1.10
sys-apps/i2c                            2.8.7               2.9.1
sys-apps/ifplugd                        0.26-r1             0.28
sys-apps/pcmcia-cs                      3.2.7-r3            3.2.8-r2
sys-cluster/lam-mpi                     7.0.4               7.0.6
sys-fs/ntfsprogs                        1.9.4               1.11.1-r1
sys-power/acpid                         1.0.2-r2            1.0.4-r2
www-client/epiphany                     1.6.3               1.6.4
x11-libs/gtk+                           2.6.7               2.6.8
x11-libs/libdockapp                     0.5.0-r1            0.6.0
x11-libs/libwnck                        2.10.0              2.10.3
x11-libs/pango                          1.8.1               1.8.1-r1
x11-libs/wxGTK                          2.4.2-r3            2.6.1
x11-plugins/desklet-starterbar          0.22.1              0.31.3-r1
x11-plugins/wmacpi                      1.99_p7             2.1_rc1
x11-plugins/wmbiff                      0.4.25              0.4.25-r1
x11-plugins/wmcoincoin                  2.5.0c              2.5.0g
x11-plugins/wmdrawer                    0.10.5              0.10.5-r1
x11-plugins/wmfishtime                  1.23-r2             1.24
x11-plugins/wmmon                       1.0_beta2-r2        1.0_beta2-r3
x11-plugins/wmnd                        0.4.11              0.4.11-r1
x11-plugins/wmpower                     0.4.1               0.4.2
x11-plugins/wmtimer                     2.4                 2.9.2
x11-plugins/wmxmms                      0.1.4               0.1.4-r1
x11-terms/mrxvt                         0.4.0-r1            0.4.1
x11-terms/rxvt-unicode                  4.0                 5.3
x11-themes/gnome-themes                 2.10.1              2.10.2
x11-themes/hicolor-icon-theme           0.5                 0.8
x11-wm/metacity                         2.10.1              2.10.3
--------------------------------------------------------------------------------
A total of 264 ebuilds seems outaded on amd64

Yes, there are a lot of "outdated" ebuilds on amd64, but practically all 
of those are because the "maintainer arch" is x86, so x86 gets bumped 
first.  Then, it is the amd64 team's responsibility to bump up their 
stable versions to match if they so choose.  Notice that for almost 
everything, amd64 is barely behind x86...just a minor version 
number/revision or two at most.

> No offense intended, but as a user, I /like/ to actually know that a
> package keyworded for my arch (segment) is known to work on it in full
> (IMHO) uncrippled amd64 form, not in some (IMHO) "crippled 32-bit special
> case". If we went the other way and removed x86 keywording from everything
> that failed in 64-bit mode, including all 32-bit only codecs and the like,
> x86(32) arch(segment) folks would rightly be wailing in protest.

I think you are pretty confused and don't know what we're talking about 
at all.  I'm not suggesting that amd64 folks keyword stuff and just 
assume it works on x86, or vice versa.  It is pretty silly to even think 
that would ever be the case.  If package maintainers coordinate closely 
with the amd64 team (which is growing quite large itself), they could 
easily work out the QA and non-working stuff well before it ever goes 
into the stable tree.  Also keep in mind that ~arch keywords mean that 
an ebuild is in testing, so it is quite possible there will be broken 
stuff floating around there.  If you are worried about your ~amd64 or 
~x86 tree breaking, you shouldn't be using them anyway.

> Again, no offense intended, but unless you have some magic way to fix that
> situation, perhaps the MIPS devs and users are willing to live with that
> problem on MIPS, but neither x86(32) users nor amd64 users (and by this
> I'm including devs, which are obviously users as well) are interested in
> being saddled with an unnecessary problem, when the current situation
> avoids it, or I expect the amd64 keyword would have never been added.

We don't "live with that problem on MIPS" because it doesn't exist.  If 
something doesn't work in one spot, we dont' stable keyword it...simple 
as that.  Also keep in mind that for some stuff, we don't have to test 
on both.  For example, we have no supported little endian machines that 
are capable of running X, therefore, we don't care about testing X 
there.  See how it works?

-Steve

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: [gentoo-core] crap use flags in the profiles

[Ciaran McCreesh]

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

On Wed, 31 Aug 2005 05:36:52 -0700 Duncan <1i5t5.duncan@cox.net> wrote:
| No offense intended, but as a user, I /like/ to actually know that a
| package keyworded for my arch (segment) is known to work on it in full
| (IMHO) uncrippled amd64 form, not in some (IMHO) "crippled 32-bit
| special case". If we went the other way and removed x86 keywording
| from everything that failed in 64-bit mode, including all 32-bit only
| codecs and the like, x86(32) arch(segment) folks would rightly be
| wailing in protest.
| 
| Again, no offense intended, but unless you have some magic way to fix
| that situation, perhaps the MIPS devs and users are willing to live
| with that problem on MIPS, but neither x86(32) users nor amd64 users
| (and by this I'm including devs, which are obviously users as well)
| are interested in being saddled with an unnecessary problem, when the
| current situation avoids it, or I expect the amd64 keyword would have
| never been added.

It's not magic. We've been handling packages that work on sparc64 but
not sparc32 for years with a single keyword. Just because you (and,
from the looks of things, most of the x86 and amd64 developers) don't
know about some of portage's features doesn't mean they don't exist :)

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] Re: [gentoo-core] crap use flags in the profiles

[Grant Goodyear]

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

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
g2boojum@gentoo.org
http://www.gentoo.org/~g2boojum
GPG Fingerprint: D706 9802 1663 DEF5 81B0  9573 A6DC 7152 E0F6 5B76

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

Re: [gentoo-dev] Re: Re: [gentoo-core] crap use flags in the profiles

[Grant Goodyear]

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

Stephen P. Becker wrote: [Wed Aug 31 2005, 08:18:53AM CDT]
> We don't "live with that problem on MIPS" because it doesn't exist.  If 
> something doesn't work in one spot, we dont' stable keyword it...simple 
> as that.  Also keep in mind that for some stuff, we don't have to test 
> on both.  For example, we have no supported little endian machines that 
> are capable of running X, therefore, we don't care about testing X 
> there.  See how it works?

So, the basic suggestion is that x86 and amd64 would both use the same
keyword, but that for cases such as valgrind pre-3.0, which didn't work
at all on amd64, then those package are profile-masked, and there's 
separate amd64 and x86 profiles (as there are now) to handle those
distinctions?

-g2boojum-
-- 
Grant Goodyear	
Gentoo Developer
g2boojum@gentoo.org
http://www.gentoo.org/~g2boojum
GPG Fingerprint: D706 9802 1663 DEF5 81B0  9573 A6DC 7152 E0F6 5B76

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

Re: [gentoo-dev] Re: Re: [gentoo-core] crap use flags in the profiles

[Chris Gianelloni]

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

On Wed, 2005-08-31 at 16:32 +0100, Ciaran McCreesh wrote:
> It's not magic. We've been handling packages that work on sparc64 but
> not sparc32 for years with a single keyword. Just because you (and,
> from the looks of things, most of the x86 and amd64 developers) don't
> know about some of portage's features doesn't mean they don't exist :)

This was kinda my point.  Developers on sparc and mips are aware of
these issues.  Developers on amd64 and x86 are not.  Forcing the merging
of these KEYWORDS would destroy the QA that already is done on these
architectures, as most of our developer pool would need some serious
training to be able to do this.  I know that *I* don't know how to do
this myself (yet), but I'm going to look into it.

Anyway, can we *please* quit hijacking this thread, as this isn't a "x86
vs. other arches" thread and rather a thread about profiles and their
USE flags.  If you want to discuss x86's defficiencies, start your own
thread, please.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead/QA Manager
Games - Developer
Gentoo Linux

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

Re: [gentoo-dev] Re: Re: [gentoo-core] crap use flags in the profiles

[Martin Schlemmer]

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

On Wed, 2005-08-31 at 16:32 +0100, Ciaran McCreesh wrote:
> On Wed, 31 Aug 2005 05:36:52 -0700 Duncan <1i5t5.duncan@cox.net> wrote:
> | No offense intended, but as a user, I /like/ to actually know that a
> | package keyworded for my arch (segment) is known to work on it in full
> | (IMHO) uncrippled amd64 form, not in some (IMHO) "crippled 32-bit
> | special case". If we went the other way and removed x86 keywording
> | from everything that failed in 64-bit mode, including all 32-bit only
> | codecs and the like, x86(32) arch(segment) folks would rightly be
> | wailing in protest.
> | 
> | Again, no offense intended, but unless you have some magic way to fix
> | that situation, perhaps the MIPS devs and users are willing to live
> | with that problem on MIPS, but neither x86(32) users nor amd64 users
> | (and by this I'm including devs, which are obviously users as well)
> | are interested in being saddled with an unnecessary problem, when the
> | current situation avoids it, or I expect the amd64 keyword would have
> | never been added.
> 
> It's not magic. We've been handling packages that work on sparc64 but
> not sparc32 for years with a single keyword. Just because you (and,
> from the looks of things, most of the x86 and amd64 developers) don't
> know about some of portage's features doesn't mean they don't exist :)

I think he expected _what_ these features are, and not a just another
'you are clueless with the rest' reply ... ?

Help us help you?


-- 
Martin Schlemmer


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

[gentoo-dev] Re: Re: Re: [gentoo-core] crap use flags in the profiles

[Duncan]

Grant Goodyear posted <20050831161516.GJ18440@bmb24.uth.tmc.edu>,
excerpted below,  on Wed, 31 Aug 2005 11:15:16 -0500:

> Stephen P. Becker wrote: [Wed Aug 31 2005, 08:18:53AM CDT]
>> We don't "live with that problem on MIPS" because it doesn't exist.  If 
>> something doesn't work in one spot, we dont' stable keyword it...simple 
>> as that.  Also keep in mind that for some stuff, we don't have to test 
>> on both.  For example, we have no supported little endian machines that 
>> are capable of running X, therefore, we don't care about testing X 
>> there.  See how it works?
> 
> So, the basic suggestion is that x86 and amd64 would both use the same
> keyword, but that for cases such as valgrind pre-3.0, which didn't work
> at all on amd64, then those package are profile-masked, and there's 
> separate amd64 and x86 profiles (as there are now) to handle those
> distinctions?

Thanks!...  Now that's something concrete enough to wrap my brain around,
which is exactly what I was asking for.  Consider the "magic" explained.
Like so much "magic", there's a perfectly good explanation, once you grasp
the concept!  =8^)

I still don't necessarily think it's the best solution for a problem that
seems decently solved as it is (not that my opinion really counts anyway,
as just a user, not one of the many actually doing the work), but at
least I have a clue about how it can be done, now, something I was lacking
the "Eureka moment" necessary to grasp, previously. =8^)  Now I can at
least intelligently follow the debate.

-- 
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 in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] merge amd64 & x86 arches? (was: crap use flags in the profiles)

[Kevin F. Quinn]

On 31/8/2005 9:18:53, Stephen P. Becker (geoman@gentoo.org) wrote:

> Keep in mind that the *stable* trees of x86 and amd64 are actually 
> pretty close to the same versions anyway, I just ran gmsoft's imlate 
> script for amd64 vs. x86 keywords:

hmm; missed a biggie - sys-devel/gcc which is stable for amd64 at 3.4.4-r1 and stable for x86 on 3.3.5.20050130-r1.

The only way I can think of to deal with amd64/x86 differences other than via an arch keyword is to use masking in profiles.  i.e. to mark both versions stable and mask the unwanted version in 'packages'.  The downside is that what would have been a testing version is now masked by the profile, and profile masking is a much stronger statement than simply keywording ~.

Is there a way to deal with this sort of thing in profiles, without masking? 



-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: [gentoo-core] crap use flags in the profiles

[Homer Parker]

On Wed, 2005-08-31 at 09:18 -0400, Stephen P. Becker wrote:
> Notice that for almost 
> everything, amd64 is barely behind x86...just a minor version 
> number/revision or two at most.

	That's the ATs hard at work keeping us current ;)

-- 
Homer Parker
Gentoo/AMD64 Arch Tester Strategic Lead
hparker@gentoo.org

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: [gentoo-core] crap use flags in the profiles

[Donnie Berkholz]

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