[gentoo-dev] Hardened PHP now in Gentoo

[gentoo-dev] Hardened PHP now in Gentoo

[Stuart Herbert]

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

Hiya,

I've just added support for the Hardened PHP patch to Portage.  To include 
Hardened PHP, add the local USE flag 'hardenedphp' before you build 
dev-php/mod_php.

Best regards,
Stu
-- 
Stuart Herbert                                              stuart@gentoo.org
Gentoo Developer                                       http://www.gentoo.org/
                                                   http://stu.gnqs.org/diary/

GnuPG key id# F9AFC57C available from http://pgp.mit.edu
Key fingerprint = 31FB 50D4 1F88 E227 F319  C549 0C2F 80BA F9AF C57C
--

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

Re: [gentoo-dev] Hardened PHP now in Gentoo

[Alexander Gabert]

Stuart Herbert wrote:
> Hiya,
> 
> I've just added support for the Hardened PHP patch to Portage.  To include 
> Hardened PHP, add the local USE flag 'hardenedphp' before you build 
> dev-php/mod_php.
> 
> Best regards,
> Stu
ouch

using the "hardened" keyword would suffice and not take part in USE flag 
namespace pollution?

Just my two,

Alex

--
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: [gentoo-web-user] Hardened PHP now in Gentoo

[Stuart Herbert]

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

On Tuesday 18 May 2004 07:25, Ed Wildgoose wrote:
> Why not just "use hardened"?  Do we really need yet another USE flag?
> (There are more flags than packages these days...)

Because 'hardened' means something else.  Gentoo's all about choice.

Best regards,
Stu
-- 
Stuart Herbert                                              stuart@gentoo.org
Gentoo Developer                                       http://www.gentoo.org/
                                                   http://stu.gnqs.org/diary/

GnuPG key id# F9AFC57C available from http://pgp.mit.edu
Key fingerprint = 31FB 50D4 1F88 E227 F319  C549 0C2F 80BA F9AF C57C
--

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

Re: [gentoo-dev] Re: [gentoo-web-user] Hardened PHP now in Gentoo

[Marius Mauch]

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

On 05/18/04  Stuart Herbert wrote:

> On Tuesday 18 May 2004 07:25, Ed Wildgoose wrote:
> > Why not just "use hardened"?  Do we really need yet another USE
> > flag?(There are more flags than packages these days...)
> 
> Because 'hardened' means something else.  Gentoo's all about choice.

And that's exactly the point about local USE flag bloat I posted a few
days ago. Why do we need a new flag for this? I would compare the
descriptions, but I don't find one for hardenedphp in use*.desc :(
Actually I don't see the flag anywhere (including the mod_php and php
ebuilds).

If it has to do with security enhancements I think the hardened flag
would be a perfect match unless the Gentoo Hardened team is disagreeing
completely (and as pappy already asked the same question I don't think
so).

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.

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

Re: [gentoo-dev] Re: [gentoo-web-user] Hardened PHP now in Gentoo

[Stuart Herbert]

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

On Tuesday 18 May 2004 19:16, Marius Mauch wrote:
> And that's exactly the point about local USE flag bloat I posted a few
> days ago. Why do we need a new flag for this? 

Like I said, because they are not the same thing.  

> I would compare the 
> descriptions, but I don't find one for hardenedphp in use*.desc :(

Yup.  It seems that I forgot to commit that.  It'll be turning up shortly.

> Actually I don't see the flag anywhere (including the mod_php and php
> ebuilds).

You're looking in the wrong place.  Try the php-sapi.eclass.

> If it has to do with security enhancements I think the hardened flag
> would be a perfect match unless the Gentoo Hardened team is disagreeing
> completely (and as pappy already asked the same question I don't think
> so).

And what do we do if we add support for any of the other (and non-compatible) 
PHP security patches out there?  Renaming this USE flag would seem somewhat 
short-sighted.

I'm pro-choice, and do not agree with the idea of aggregating USE flags just 
because they sound similar.  

Best regards,
Stu
-- 
Stuart Herbert                                              stuart@gentoo.org
Gentoo Developer                                       http://www.gentoo.org/
                                                   http://stu.gnqs.org/diary/

GnuPG key id# F9AFC57C available from http://pgp.mit.edu
Key fingerprint = 31FB 50D4 1F88 E227 F319  C549 0C2F 80BA F9AF C57C
--

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

Re: [gentoo-dev] Re: [gentoo-web-user] Hardened PHP now in Gentoo

[foser]

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

On Tue, 2004-05-18 at 21:08 +0100, Stuart Herbert wrote:

> I'm pro-choice, and do not agree with the idea of aggregating USE flags just 
> because they sound similar.

The second time you mention choice. I guess we know what Gentoo is about
by now, the 'choice' argument is too often used just to end criticism.

Choice is an illusion, if you there's too much choice it is no use to
anyone anymore, because nobody really knows what it is all about. This
is already the case with the loads of USE flags/portage options/etc. we
have. Gentoo shouldn't be about choice for the sake of it, it should be
about simplicity/managability : stuff that works. It's a trade-off.

I wasn't too happy with the introducation of local USE flags for just
the reasons that are becoming a problem now. Too much flags, everybody
adds them at will without good reasons. We used to just say to people
who wanted a specific (rare) set-up that they could easily edit the
ebuild themselves to their need, but nowadays it seems we have to hold
hands all the time and add complexity for nothing. That's good for
nobody really. The installation manual used to be like 5 pages, by now
it's a book of it's own per arch. I don't think that's a good thing and
we should be really, really careful about what we can do to stop this
movement.

- foser

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

Re: [gentoo-dev] Re: [gentoo-web-user] Hardened PHP now in Gentoo

[Josh Glover]

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

Quoth foser (Wed 2004-05-19 01:30:00PM +0200):

> On Tue, 2004-05-18 at 21:08 +0100, Stuart Herbert wrote:
> 
> > I'm pro-choice, and do not agree with the idea of aggregating USE flags just 
> > because they sound similar.
> 
> The second time you mention choice. I guess we know what Gentoo is about
> by now, the 'choice' argument is too often used just to end criticism.
> 
> Choice is an illusion, if you there's too much choice it is no use to
> anyone anymore, because nobody really knows what it is all about. This
> is already the case with the loads of USE flags/portage options/etc. we
> have. Gentoo shouldn't be about choice for the sake of it, it should be
> about simplicity/managability : stuff that works. It's a trade-off.

That is ridiculous. Speaking from personal experience, choice is exactly
what drew me to Gentoo--I could have it *just* how I wanted it. Thus,
choice is *not* an illusion, it is vital to many advanced users who
have chosen Gentoo for just that reason.

The way to achieve "simplicity/managability : stuff that works" is
through reasonable defaults. Look at all the USE flags that xfree or
xemacs use. Quite a glut. However, the defaults are almost always what
I need. If I care enough, I can run 'equery uses' to find out what the
more esoteric flags do, and select or deselect flags based on that.

If I want things to Just Work(TM), I accept the Gentoo defaults,
knowing that the devs would never lead me down the wrong path. :)


-- 
Josh Glover

Gentoo Developer (http://dev.gentoo.org/~jmglov/)
Tokyo Linux Users Group Listmaster (http://www.tlug.jp/)

GPG keyID 0xDE8A3103 (C3E4 FA9E 1E07 BBDB 6D8B  07AB 2BF1 67A1 DE8A 3103)
gpg --keyserver pgp.mit.edu --recv-keys DE8A3103

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

Re: [gentoo-dev] Re: [gentoo-web-user] Hardened PHP now in Gentoo

[foser]

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

On Wed, 2004-05-19 at 08:30 -0400, Josh Glover wrote:
> > Choice is an illusion, if you there's too much choice it is no use to
> > anyone anymore, because nobody really knows what it is all about. This
> > is already the case with the loads of USE flags/portage options/etc. we
> > have. Gentoo shouldn't be about choice for the sake of it, it should be
> > about simplicity/managability : stuff that works. It's a trade-off.
> 
> That is ridiculous. Speaking from personal experience, choice is exactly
> what drew me to Gentoo--I could have it *just* how I wanted it. Thus,
> choice is *not* an illusion, it is vital to many advanced users who
> have chosen Gentoo for just that reason.

You have the choice. The real power is the easy way in which you can
adapt it to your needs and the simplicity of doing so. Huge loads of
nobody-ever-uses them options don't help one bit. You should keep it
basic for exactly the reason that anyone can adapt it easily. Adding
layers of complexity leads to a system that needs time & effort to get
into : you lose what you want, you lose the true power.
Actually i consider 'advanced users' the people who have a basic system
setup and adapted/created several ebuilds to their needs on top of that,
not the ones who want an extra USE flag for everything under the sun.

> The way to achieve "simplicity/managability : stuff that works" is
> through reasonable defaults. Look at all the USE flags that xfree or
> xemacs use. Quite a glut. However, the defaults are almost always what
> I need. If I care enough, I can run 'equery uses' to find out what the
> more esoteric flags do, and select or deselect flags based on that.

You actually prove my point with your example. The defaults should be
good enough, all the extra stuff is mostly cruft in 99.9% of the cases.
That cruft therefore isn't necessary in the distro, keeping the playing
field clean and open.
Anyway, eg. xfree is all basic and understandable USE flags like they
should be. You don't need no extra tools to explain what a USE flag
does, but you say you need 'equery' to figure out the uses. That's
exactly the thing i'm talking about : we already are starting to require
extra info to make decisions. That is what should be avoided. We're
creating tools to be able to work with our tools, thats in indication of
going the wrong way.

> If I want things to Just Work(TM), I accept the Gentoo defaults,
> knowing that the devs would never lead me down the wrong path. :)

Nuf said.

- foser

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

Re: [gentoo-dev] Re: [gentoo-web-user] Hardened PHP now in Gentoo

[Jon Portnoy]

On Wed, May 19, 2004 at 04:09:10PM +0200, foser wrote:
> On Wed, 2004-05-19 at 08:30 -0400, Josh Glover wrote:
> > > Choice is an illusion, if you there's too much choice it is no use to
> > > anyone anymore, because nobody really knows what it is all about. This
> > > is already the case with the loads of USE flags/portage options/etc. we
> > > have. Gentoo shouldn't be about choice for the sake of it, it should be
> > > about simplicity/managability : stuff that works. It's a trade-off.
> > 
> > That is ridiculous. Speaking from personal experience, choice is exactly
> > what drew me to Gentoo--I could have it *just* how I wanted it. Thus,
> > choice is *not* an illusion, it is vital to many advanced users who
> > have chosen Gentoo for just that reason.
> 
> You have the choice. The real power is the easy way in which you can
> adapt it to your needs and the simplicity of doing so. Huge loads of
> nobody-ever-uses them options don't help one bit.

Except that people _do_ use them.

> You should keep it
> basic for exactly the reason that anyone can adapt it easily. Adding
> layers of complexity leads to a system that needs time & effort to get
> into : you lose what you want, you lose the true power.

"True power"? Can you elaborate?

> Actually i consider 'advanced users' the people who have a basic system
> setup and adapted/created several ebuilds to their needs on top of that,
> not the ones who want an extra USE flag for everything under the sun.
> 

Why not save them the hassle with a couple extra lines? This is the 
point of local USE flags: very specific tweaking for very specific needs 
to provide powerful options out of the box. This is a major advantage 
Gentoo has over binary distributions: you can build everything precisely 
how you want it right out of the box rather than having a vendor make 
those choices for you (and then say "well, if you don't like it, make 
your own packages" which is the equivalent of "if you don't like it, 
edit the ebuilds").

> > The way to achieve "simplicity/managability : stuff that works" is
> > through reasonable defaults. Look at all the USE flags that xfree or
> > xemacs use. Quite a glut. However, the defaults are almost always what
> > I need. If I care enough, I can run 'equery uses' to find out what the
> > more esoteric flags do, and select or deselect flags based on that.
> 
> You actually prove my point with your example. The defaults should be
> good enough, all the extra stuff is mostly cruft in 99.9% of the cases.
> That cruft therefore isn't necessary in the distro, keeping the playing
> field clean and open.

Sure, it isn't strictly speaking _necessary_. USE flags in general 
aren't _necessary_. CFLAGS in make.conf isn't _necessary_ either -- we 
could pick defaults that are "good enough" instead. Instead, we let the 
end user make that choice.

-- 
Jon Portnoy
avenj/irc.freenode.net

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: [gentoo-web-user] Hardened PHP now in Gentoo

[foser]

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

On Wed, 2004-05-19 at 12:13 -0400, Jon Portnoy wrote:
> > You have the choice. The real power is the easy way in which you can
> > adapt it to your needs and the simplicity of doing so. Huge loads of
> > nobody-ever-uses them options don't help one bit.
> 
> Except that people _do_ use them.

Relatively speaking. Sure there's always a few users using them, but is
it worth what it adds in complexity ?

> > You should keep it
> > basic for exactly the reason that anyone can adapt it easily. Adding
> > layers of complexity leads to a system that needs time & effort to get
> > into : you lose what you want, you lose the true power.
> 
> "True power"? Can you elaborate?

True power is simplicity, being able to make changes without digging
trough loads of shell/python/etc. script to get what you want.

> > Actually i consider 'advanced users' the people who have a basic system
> > setup and adapted/created several ebuilds to their needs on top of that,
> > not the ones who want an extra USE flag for everything under the sun.
> > 
> 
> Why not save them the hassle with a couple extra lines? This is the 
> point of local USE flags: very specific tweaking for very specific needs 
> to provide powerful options out of the box. This is a major advantage 
> Gentoo has over binary distributions: you can build everything precisely 
> how you want it right out of the box rather than having a vendor make 
> those choices for you (and then say "well, if you don't like it, make 
> your own packages" which is the equivalent of "if you don't like it, 
> edit the ebuilds").

To start : it is not equivalent, binary packaging is a mess of it's own
and ebuilding is starting to go that same way. And it used to be
perfectly fine to say such things ('edit it to your needs') and people
accepted that, because it was (is?) a breeze to edit simple builds
script for example. But somewhere along the way we moved to holding
hands for even the most obscure of setups.

The hassle is that the 'couple of lines' you add time and time again
expand into seriously large ebuilds with stacked layers of eclass and
portage functionality, losing that hands-on touch with the actual
buildscript. That's where you lose the 'true power'.

> Sure, it isn't strictly speaking _necessary_. USE flags in general 
> aren't _necessary_. CFLAGS in make.conf isn't _necessary_ either -- we 
> could pick defaults that are "good enough" instead. Instead, we let the 
> end user make that choice.

You take my point too far, yes it's easy to dismiss this by deploying
the over-used 'Gentoo is about choice' mantra (wasn't Gentoo also about
bleeding edge, configurability.. hmm whatever i can use in the
discussion). No, that's not what i want. I want the simplicity back, the
power to say 'no' to certain things because they do make it harder and
harder to use Gentoo as a real tool for personal distro management.
Increasing complexity makes it harder to control on an individual level.

btw. 10-20% of the bugs the gnome team gets turns out to be CFLAGS
related, I sometimes wish we wouldn't had made using insane CFLAGs so
easy. 

- foser

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

[gentoo-dev] Some numbers

[Stuart Herbert]

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

On Thursday 20 May 2004 16:52, foser wrote:
> Relatively speaking. Sure there's always a few users using them, but is
> it worth what it adds in complexity ?

What is it adding in terms of complexity?  For most ebuilds, I believe the 
answer is bugger all.

I agree that there's a problem with ufed - and I'm one of the people who think 
that a tree-structure for USE flags would help them scale better.  After all, 
we have less USE flags than the Linux kernel has options ...

> True power is simplicity, being able to make changes without digging
> trough loads of shell/python/etc. script to get what you want.

Isn't that a problem with the tools, rather than the concept?

> To start : it is not equivalent, binary packaging is a mess of it's own
> and ebuilding is starting to go that same way. 

> And it used to be 
> perfectly fine to say such things ('edit it to your needs') and people
> accepted that, because it was (is?) a breeze to edit simple builds
> script for example. 

Having to maintain local ebuilds, and keep them in sync with changes from 
Gentoo, is a lot of work.  It's an idea that doesn't scale, as I mentioned 
elsewhere in this thread.

I mean no disrespect to you personally, but going to this would not only be a 
step backwards, it would be a stupid solution.  You'd be pushing the wrong 
type of work onto our users, and you wouldn't be solving the complexity issue 
either.

> The hassle is that the 'couple of lines' you add time and time again
> expand into seriously large ebuilds with stacked layers of eclass and
> portage functionality, losing that hands-on touch with the actual
> buildscript. That's where you lose the 'true power'.

Yes, there are some ebuilds and eclasses that are complicated.  The PHP builds 
are a good example of that.  webapp.eclass, and the whole webapp-config 
approach, is another example.  webapp-config effectively extends Portage by 
an additional 2,500 lines of code.  By the time I stop adding features, and 
we have vhost-config available too, that'll probably be nearer 5-6,000 lines.

But they provide simplicity, because they move complexity away from the user 
and hide it behind a simple interface.

They would stand up fairly well to a review from a de-Bono like Ministry of 
Simplicity.

The vast majority of packages with USE flags do little more than the 
equivalent of use_enable().  Hardly a maintenance nightmare.  If users were 
compiling each package by hand, they'd have to look at the --with and 
--enable options for each package anyway, to make their decisions on what 
they did and did not want enabled.

Let's have a look at some numbers.

We have 95 eclasses, for over 8,200 ebuilds.  Interestingly, 8,043 ebuilds 
appear to inherit one or more eclass, probably because most of them inherit 
the eutils eclass.  There was a spate of agriffis going round and adding that 
to ebuilds recently withing asking first (grrr).

92% of all ebuilds are 100 lines long or less.  That leaves over 1,100 ebuilds 
that are 101 lines long or more.  Of course, this includes packages with 
multiple ebuilds in.

Only 22% of ebuilds are 25 lines long or less.  So 78% of ebuilds are too long 
to fit in a standard console without scrolling, and 70% of all ebuilds are 
between 100 and 25 lines.

I know that numbers aren't everything, but these ones don't appear to be 
saying that we have a general problem of complexity.

Are you complaining that *your* ebuilds are too complicated?  (Doubt that)  Or 
that specific named ebuilds are too complicated?

Or are you just complaining?

Best regards,
Stu
-- 
Stuart Herbert                                              stuart@gentoo.org
Gentoo Developer                                       http://www.gentoo.org/
                                                   http://stu.gnqs.org/diary/

GnuPG key id# F9AFC57C available from http://pgp.mit.edu
Key fingerprint = 31FB 50D4 1F88 E227 F319  C549 0C2F 80BA F9AF C57C
--

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

Re: [gentoo-dev] Some numbers

[foser]

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

On Thu, 2004-05-20 at 22:10 +0100, Stuart Herbert wrote:
> On Thursday 20 May 2004 16:52, foser wrote:
> > Relatively speaking. Sure there's always a few users using them, but is
> > it worth what it adds in complexity ?
> 
> What is it adding in terms of complexity?  For most ebuilds, I believe the 
> answer is bugger all.

It's overall complexity, not on a per package basis. Sure it's a few
lines here and there, but if you add it all up... plus that it builds up
over time.

> I agree that there's a problem with ufed - and I'm one of the people who think 
> that a tree-structure for USE flags would help them scale better.  After all, 
> we have less USE flags than the Linux kernel has options ...

Don't talk USE flags/ufed all the time, USE flags are only an example of
the problem. This is an overall conceptual tendency to add complexity
for no good reasons.

Is the linux kernel a good example here, didn't we create a tool for
that to handle it's options ? Is that what we need to do for Gentoo's
options as well, to dumb it down enough for a casual user ?

> > True power is simplicity, being able to make changes without digging
> > trough loads of shell/python/etc. script to get what you want.
> 
> Isn't that a problem with the tools, rather than the concept?

Hardly, the tools we basicly have are python mixed with shell. It's the
abstraction layers that got added : portage functions, layered eclasses,
etc. Usually editting an ebuild is not enough anymore and has become a
science in itself.

> > To start : it is not equivalent, binary packaging is a mess of it's own
> > and ebuilding is starting to go that same way. 
> 
> > And it used to be 
> > perfectly fine to say such things ('edit it to your needs') and people
> > accepted that, because it was (is?) a breeze to edit simple builds
> > script for example. 
> 
> Having to maintain local ebuilds, and keep them in sync with changes from 
> Gentoo, is a lot of work.  It's an idea that doesn't scale, as I mentioned 
> elsewhere in this thread.

On a general system this isn't needed, so there's not much to scale.
Most advanced users already have extensive local trees, so it seems to
scale well enough. But -as said- support for local stuff is sort of
rudimentary and could be improved if needed.

You shouldn't stare blind at what there is now : it is depressing. Look
at what it can be.

> I mean no disrespect to you personally, but going to this would not only be a 
> step backwards, it would be a stupid solution.  You'd be pushing the wrong 
> type of work onto our users, and you wouldn't be solving the complexity issue 
> either.

A general user would probably never see the need to make ebuild changes
themselves, because the defaults are good enough for the majority of
users. And for the advanced users it would be easier to adapt it to
their needs. After all Gentoo is trying to be a meta-distro, we basicly
give the possibility to adapt it to your needs in a sane and simple way.
That doesn't mean we have to hold hands for everything, I think that's
an insult to our users.
Gentoo was built on the notion that everyone could easily help out, fix
ebuilds and report to us. Why is it suddenly a bad thing to emphasize
that strength in Gentoo once again.

> Yes, there are some ebuilds and eclasses that are complicated.  The PHP builds 
> are a good example of that.  webapp.eclass, and the whole webapp-config 
> approach, is another example.  webapp-config effectively extends Portage by 
> an additional 2,500 lines of code.  By the time I stop adding features, and 
> we have vhost-config available too, that'll probably be nearer 5-6,000 lines.
> 
> But they provide simplicity, because they move complexity away from the user 
> and hide it behind a simple interface.
> 
> They would stand up fairly well to a review from a de-Bono like Ministry of 
> Simplicity.

Simplicity for someone who wants to use such a setup, but it is far away
from the simplicity where users can figure out problems with their local
web application they just turned into an ebuild.

I'm not saying i don't like you webapp project, to be honest I haven't
looked at it at all because I don't use that stuff. But in general I
don't like my ebuilds to do all sorts of magical stuff behind by my
back.

> The vast majority of packages with USE flags do little more than the 
> equivalent of use_enable().  Hardly a maintenance nightmare.  If users were 
> compiling each package by hand, they'd have to look at the --with and 
> --enable options for each package anyway, to make their decisions on what 
> they did and did not want enabled.

I'm not talking maintenance only, it's also on a user level where users
have no idea what something means. Where use flags have become a large
row of anonymous magical words that do something, but you never know
what exactly.

Nothing personal, but what I only get here (in the whole thread) is such
a focus on the USE flag issue and arguing for it. That is pretty much
missing the complete point, it's a conceptual approach that affects much
more than USE flags alone. It's a way of thinking.

> Let's have a look at some numbers.

Numbers, nothing as multi interpretable. Let's see what it proves for
you today.

> We have 95 eclasses, for over 8,200 ebuilds.  Interestingly, 8,043 ebuilds 
> appear to inherit one or more eclass, probably because most of them inherit 
> the eutils eclass.  There was a spate of agriffis going round and adding that 
> to ebuilds recently withing asking first (grrr).
> 
> 92% of all ebuilds are 100 lines long or less.  That leaves over 1,100 ebuilds 
> that are 101 lines long or more.  Of course, this includes packages with 
> multiple ebuilds in.
> 
> Only 22% of ebuilds are 25 lines long or less.  So 78% of ebuilds are too long 
> to fit in a standard console without scrolling, and 70% of all ebuilds are 
> between 100 and 25 lines.
> 
> I know that numbers aren't everything, but these ones don't appear to be 
> saying that we have a general problem of complexity.
> 
> Are you complaining that *your* ebuilds are too complicated?  (Doubt that)  Or 
> that specific named ebuilds are too complicated?

Well get your mind out from the numbers into a more creative mood where
complexity lies not just in size of ebuilds or exact number of inherited
eclasses.

Vision the future of Gentoo where we add complexity because we can and
we end with a distro that can do anything, but nobody really knows
exactly how to do it or it can be done in x different ways.
Or let's evaluate every change if it really adds something to Gentoo
that is beyond 'craze of the day' type of fixes and we keep Gentoo lean,
nimble and simple.
Which future Gentoo do you prefer ?

It's a broader vision than mere USE flags or size of ebuilds.

> Or are you just complaining?

What are you insinuating? Here you really say what you are trying to say
troughout your whole mail. You could've skipped a lot of the stuff up
there.

You probably feel offended that this thread came into being after your
initial USE flag proposal. It was merely a point in time where i put
some thoughts out i've had for a long time. It's not directly related to
your proposal there, it was just a catalyst.

If having a broader vision than just today's Gentoo is complaining to
you... well..

- foser

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

Re: [gentoo-dev] Some numbers

[Stuart Herbert]

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

On Thursday 20 May 2004 23:30, foser wrote:
> > What is it adding in terms of complexity?  For most ebuilds, I believe
> > the answer is bugger all.
>
> It's overall complexity, not on a per package basis. Sure it's a few
> lines here and there, but if you add it all up... plus that it builds up
> over time.

Yes, things are getting more complicated.  I agree with you.  But I don't 
agree with you that the solution is to reduce Gentoo's functionality and 
value.

> Don't talk USE flags/ufed all the time, USE flags are only an example of
> the problem. This is an overall conceptual tendency to add complexity
> for no good reasons.

It's the nature of man to complicate things.  It's like common sense.  If 
common sense actually was common, we wouldn't talk about it so much.

But what would you prefer?  To deliver a Gentoo with much less functionality?

> Is the linux kernel a good example here, didn't we create a tool for
> that to handle it's options ? 

You mean genkernel?  I thought we built that to protect non-technical users 
from themselves ;-)

> Is that what we need to do for Gentoo's 
> options as well, to dumb it down enough for a casual user ?

Maybe it is.

> Hardly, the tools we basicly have are python mixed with shell. 

The tools are *written* in python mixed in shell.  It's not the same thing.

And it's the UNIX way to have tools that work with other tools.  I think 
Portage is currently way too monolithic, and as part of the work on 
webapp-config I've made an offer to the Portage devs to help them with the 
restructuring.  webapp-config would immensely benefit from Portage being made 
from a more discrete set of tools.

> It's the 
> abstraction layers that got added : portage functions, layered eclasses,
> etc. Usually editting an ebuild is not enough anymore and has become a
> science in itself.

Am I the only person who doesn't think that writing ebuilds is particularly 
difficult?  In terms of programming skill, all you need to be able to do is a 
little shell scripting.  Bash has a few features that UNIX v7's /bin/sh has, 
but believe you me you're probably not making much use of them.

The portage functions add simplicity - they provide re-usable functionality.  
The eclasses work in a sane manner - anyone with modern training in 
programming should have no trouble at all in picking up the concepts there.

Shell scripting as a programming skill is ... nothing.  As far as lowering the 
bar goes, you can't get any lower on a UNIX system.  Just using the command 
prompt on a UNIX system is a form of shell programming.  The structure of an 
ebuild is not complicated at all.  You've got your basic functions, and some 
global variables.  That's a programming paradigm that's supported directly in 
the machine code of whatever processor you use.

Eclasses are sort-of trying to fake OO.  They're following sound - and basic - 
engineering principles that you'll find taught in any credible computer 
programming educational course.

How would you prefer ebuilds to share reusable code?

> > Having to maintain local ebuilds, and keep them in sync with changes from
> > Gentoo, is a lot of work.  It's an idea that doesn't scale, as I
> > mentioned elsewhere in this thread.
>
> On a general system this isn't needed, so there's not much to scale.
> Most advanced users already have extensive local trees, so it seems to
> scale well enough. 

I challenge you to provide numbers to support that claim.  

It would be interesting to know whether users have extensive local trees of 
packages that also exist in Portage, or whether what they really have are 
trees of packages that don't exist in Portage.

> But -as said- support for local stuff is sort of 
> rudimentary and could be improved if needed.
>
> You shouldn't stare blind at what there is now : it is depressing. Look
> at what it can be.

I'm all for making it better.  But to be honest, I find the idea that you're 
putting forward to be more depressing than what we have today.

> And for the advanced users it would be easier to adapt it to 
> their needs. 

If just two advanced users have to make the same change in local copies of 
ebuilds, that's already duplicated effort.  We have a user base of what?  
10,000?  100,000?

It doesn't scale.

> After all Gentoo is trying to be a meta-distro, we basicly 
> give the possibility to adapt it to your needs in a sane and simple way.
> That doesn't mean we have to hold hands for everything, I think that's
> an insult to our users.

But what do our users think?  Maybe, like Josh, they were *attracted* to 
Gentoo because of the flexibility that it delivers.

Let me put it to you another way.  I maintain a number of UNIX servers as part 
of my job.  The single most expensive overhead of maintaining those servers 
is the amount of manual tailoring and compiling that has to be done - because 
the UNIX operating systems on those machines give you a one-size-fits-none 
solution to their packages.

In contrast, the Gentoo boxes normally cost the business a lot less.  The 
biggest cost there are upgrades to the toolchain and python when they go 
wrong.

> Gentoo was built on the notion that everyone could easily help out, fix
> ebuilds and report to us. Why is it suddenly a bad thing to emphasize
> that strength in Gentoo once again.

I think it's a good idea to emphasise that strength, and to make it stronger.

But I also think your solution falls into the dumbing down category.  I 
wouldn't call it simple, I'd call it simplistic - perhaps even an over 
simplification.

> Simplicity for someone who wants to use such a setup, but it is far away
> from the simplicity where users can figure out problems with their local
> web application they just turned into an ebuild.

I'm sure webapp-config can be improved, but from the feedback I've had, I'd 
say that the main problem people have (apart from my stupid bugs ;-) is that 
they just don't h.a.f.c. about virtual hosting.

Things should be made easier for people - but also people should expect to 
have to achieve a certain level of education in a particular area too.  Right 
now, for webapp-config, those educational materials are at best incomplete.

> I'm not saying i don't like you webapp project, to be honest I haven't
> looked at it at all because I don't use that stuff. But in general I
> don't like my ebuilds to do all sorts of magical stuff behind by my
> back.

You wouldn't like webapp-config then ;-)  We took a deliberate decision to 
make it always do the magical stuff, so that the upgrade path from single 
host to vhosting was trivial.

> I'm not talking maintenance only, it's also on a user level where users
> have no idea what something means. Where use flags have become a large
> row of anonymous magical words that do something, but you never know
> what exactly.

I think those are problems that can - and should - be fixed without having to 
rip out the whole idea of USE flags.  Get rid of the flat namespace, sort out 
the poor documentation of most USE flags, and improve ufed.

At the very least, those steps need doing until the day we get rid of USE 
flags.

> Nothing personal, but what I only get here (in the whole thread) is such
> a focus on the USE flag issue and arguing for it. That is pretty much
> missing the complete point, it's a conceptual approach that affects much
> more than USE flags alone. It's a way of thinking.

I'm arguing for the functionality that USE flags currently provide - and 
against your suggestion that we should just drop that functionality.

I have no personal attachment to USE flags.  If someone can invent a better 
paradigm, then I'm offering to help code it.  There's a real opportunity to 
do something truly wonderful here.  USE flags are useful to many people, but 
they're pretty much the equivalent of features in MSI installers.  They're 
only something novel in the UNIX world.  If we can invent and deliver a 
better paradigm, I think that'd be wonderful.

> Numbers, nothing as multi interpretable. Let's see what it proves for
> you today.

Numbers play an important part in any reasonable justification, whether it's a 
business plan, a scientific theory, or engineering practice.  Computing is 
just a rather small subset of maths after all ;-)

> Well get your mind out from the numbers into a more creative mood where
> complexity lies not just in size of ebuilds or exact number of inherited
> eclasses.

I think you should get into the numbers.  The numbers suggest that the problem 
of overly-complicated ebuilds and massive layerings of eclasses does not 
exist - at least on a large scale.  There's still those 1,100 or so ebuilds 
that are much larger than the rest.  It's perfectly possible that some of 
those have become overly-complex.

> Vision the future of Gentoo where we add complexity because we can and
> we end with a distro that can do anything, but nobody really knows
> exactly how to do it or it can be done in x different ways.

That's one possible outcome.  I don't believe that we are collectively 
steering the good ship Gentoo straight over the waterfall tho ;-)

> Or let's evaluate every change if it really adds something to Gentoo
> that is beyond 'craze of the day' type of fixes and we keep Gentoo lean,
> nimble and simple.
> Which future Gentoo do you prefer ?

I can't speak for other devs, but I only add and maintain stuff that I 
actually use or that I understand enough to maintain and support.

Can you provide examples where 'craze of the day' is happening?  Or examples 
of specific ebuilds that are somehow too complicated?

Arguments of vision and abstraction are all well and good, but sooner or later 
you've got to get down into the detail to support or counter any argument.  
No matter how I try, I haven't managed to get you to provide that detail yet.

> It's a broader vision than mere USE flags or size of ebuilds.

Again, I personally think it's a simplistic vision and not a broader one.  But 
at least someone is thinking about how to make Gentoo simpler - that can only 
be a good thing.

> > Or are you just complaining?
>
> What are you insinuating? Here you really say what you are trying to say
> troughout your whole mail. You could've skipped a lot of the stuff up
> there.

I'd better explain.  I'm using po - I'm deliberately provoking you.  It's a 
recognised debating technique.

Why am I doing this?  Partly because I'm trying to understand you better.  
Partly because in the back of my mind you do remind me of a type of person 
who I find falls somewhere between useless and dangerous.  I'm not saying you 
are either - I don't know you.  But I'm curious to find out ;-)

I hope you're coming over to the Gentoo meetup that Bass is organising later 
this year.  I think one of Gentoo's weaknesses is that so few of us actually 
do know each other offline.  We'd all work together better for having met 
each other at least the once.

> You probably feel offended that this thread came into being after your
> initial USE flag proposal. 

Not at all.  Surely by now you've realised that I enjoy a good debate? :)

> If having a broader vision than just today's Gentoo is complaining to
> you... well..
>
> - foser

Actually, I get very little feedback (good or bad) about my contributions to 
Gentoo.  One of my motivations behind the UK charity is to try and have 
*much* more contact with users, and to help generate the funds to send UK 
devs off around the world to do the same.

As regards a vision - personally I'm comfortable with the way ebuilds and 
eclasses work.  I'm wary of the occaisionally-mentioned plans to replace 
ebuilds with yet-more-XML, because that's very similar to how Microsoft's MSI 
installer works - and personally I don't believe MSI has been a step forward.  
Now *that* is an idea that I believe is complexity for the sake of it.  A few 
years ago, Java was the fad.  Unfortunately, today it seems to be XML :(

Best regards,
Stu
-- 
Stuart Herbert                                              stuart@gentoo.org
Gentoo Developer                                       http://www.gentoo.org/
                                                   http://stu.gnqs.org/diary/

GnuPG key id# F9AFC57C available from http://pgp.mit.edu
Key fingerprint = 31FB 50D4 1F88 E227 F319  C549 0C2F 80BA F9AF C57C
--

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

Re: [gentoo-dev] Some numbers

[Grant Goodyear]

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

> I'd better explain.  I'm using po - I'm deliberately provoking you.  It's a 
> recognised debating technique.

Deliberately provoking somebody may be a recognized debating technique,
but less sophisticated types such as lil' ol' me will see such
techniques as merely being rude and offensive.  E-mail is horribly
susceptible to misinterpretation as it is, so my personal opinion is
that it behooves all of us to try to avoid inciting additional flame
wars.  

Once upon a time (and formulated mostly in e-mail and irc discussions
between drobbins and danarmak), the USE flag issue could be summarized
as "Usability, flexibility, and maintainability are all important.  USE
flags should be  used for significant optional functionality.  Optional
functionality that almost everybody would want and that has a minimal
footprint should be enabled by default w/o a USE flag."  My personal
opinion is that for new packages this process is a pretty good one.
Over time one learns from the community what additional functionality
people want to see in a package, and new (local or global) USE flags get
added *at the maintainer's discretion*.  I understand that the
potentially overwhelming number of USE flags may require us to change
this policy, but first there needs to be some solid, clearly-explained
proposals put on the table.  Send me some GLEPs, and I'll get them
posted.

A couple of minor notes:  When I read the original thread complaining
about foser's refusal to add a USE flag that, in his opinion, would have
produced a broken package, most comments that I saw agreed w/ foser's
decision.  (I didn't post a comment, but I did think that foser's
argument was quite good.)  So clearly it is the case that we are not
striving for "maximal flexibility" but for "maximal, but not insane,
flexibility".  

Foser, if you could provide either specific details about how you think
USE flags (and CFLAGS, etc) should be handled, I would be interested in
reading it.  I do understand your arguments, but in this thread they
have been a bit too vague for me to really understand precisely what you
are proposing.  

Stuart, please also feel free to write up a GLEP on any thoughts you
might have about USE flags.

Best,
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: [gentoo-web-user] Hardened PHP now in Gentoo

[Jon Portnoy]

On Wed, May 19, 2004 at 01:30:00PM +0200, foser wrote:
> On Tue, 2004-05-18 at 21:08 +0100, Stuart Herbert wrote:
> 
> > I'm pro-choice, and do not agree with the idea of aggregating USE flags just 
> > because they sound similar.
> 
> The second time you mention choice. I guess we know what Gentoo is about
> by now, the 'choice' argument is too often used just to end criticism.
> 
> Choice is an illusion, if you there's too much choice it is no use to
> anyone anymore, because nobody really knows what it is all about. This
> is already the case with the loads of USE flags/portage options/etc. we
> have. Gentoo shouldn't be about choice for the sake of it, it should be
> about simplicity/managability : stuff that works. It's a trade-off.
> 
> I wasn't too happy with the introducation of local USE flags for just
> the reasons that are becoming a problem now. Too much flags, everybody
> adds them at will without good reasons. We used to just say to people
> who wanted a specific (rare) set-up that they could easily edit the
> ebuild themselves to their need, but nowadays it seems we have to hold
> hands all the time and add complexity for nothing. That's good for
> nobody really. The installation manual used to be like 5 pages, by now
> it's a book of it's own per arch. I don't think that's a good thing and
> we should be really, really careful about what we can do to stop this
> movement.
> 
> - foser

The users seem to be perfectly happy with having a maximum of choice via 
local USE flags. Most people are also okay with the handbook. So what's 
the problem, exactly? Should we force everyone to do what _you_ want 
rather than what _they_ want?

-- 
Jon Portnoy
avenj/irc.freenode.net

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: [gentoo-web-user] Hardened PHP now in Gentoo

[Olivier Crete]

> On Wed, May 19, 2004 at 01:30:00PM +0200, foser wrote:
>> On Tue, 2004-05-18 at 21:08 +0100, Stuart Herbert wrote:
>>
>> > I'm pro-choice, and do not agree with the idea of aggregating USE
>> > flags just  because they sound similar.
>>
>> The second time you mention choice. I guess we know what Gentoo is
>> about by now, the 'choice' argument is too often used just to end
>> criticism.
>>
>> Choice is an illusion, if you there's too much choice it is no use to
>> anyone anymore, because nobody really knows what it is all about. This
>> is already the case with the loads of USE flags/portage options/etc.
>> we have. Gentoo shouldn't be about choice for the sake of it, it
>> should be about simplicity/managability : stuff that works. It's a
>> trade-off.
>>
>> I wasn't too happy with the introducation of local USE flags for just
>> the reasons that are becoming a problem now. Too much flags, everybody
>> adds them at will without good reasons. We used to just say to people
>> who wanted a specific (rare) set-up that they could easily edit the
>> ebuild themselves to their need, but nowadays it seems we have to hold
>> hands all the time and add complexity for nothing. That's good for
>> nobody really. The installation manual used to be like 5 pages, by now
>> it's a book of it's own per arch. I don't think that's a good thing
>> and we should be really, really careful about what we can do to stop
>> this movement.
>>
>> - foser
>
> The users seem to be perfectly happy with having a maximum of choice
> via  local USE flags. Most people are also okay with the handbook. So
> what's  the problem, exactly? Should we force everyone to do what _you_
> want  rather than what _they_ want?

There is at least one other guy who thinks that the handbook has gotten
way too long (me)...And foser is right on choice, too much is worst that too little, because
you end up not being able to find out howto where to configure stuff..
Gentoo is all about choice and choice is good.. But I dont want to have to
go thourhg 800 use flags before I can install a gentoo system.. I used to
be able to run ufed and set all of the use flags that I wanted for a
system... I tried doing that yesterday.. the list has just gotten out of
proportion.

-- 
Olivier Crete
tester@gentoo.org
Gentoo Developer



--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: [gentoo-web-user] Hardened PHP now in Gentoo

[Ciaran McCreesh]

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

On Wed, 19 May 2004 19:26:34 +0200 (CEST) Olivier Crete
<tester@gentoo.org> wrote:
| There is at least one other guy who thinks that the handbook has
| gotten way too long (me)...

...which is why we have the quickinstall guides, which are aimed at
people who already know (more or less) what they're doing.

-- 
Ciaran McCreesh, Gentoo XMLcracy Member G03X276
(Sparc, MIPS, Vim, si hoc legere scis nimium eruditionis habes)
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-web-user] Hardened PHP now in Gentoo

[Jon Portnoy]

On Wed, May 19, 2004 at 07:26:34PM +0200, Olivier Crete wrote:
> 
> There is at least one other guy who thinks that the handbook has gotten
> way too long (me)...And foser is right on choice, too much is worst that too little, because
> you end up not being able to find out howto where to configure stuff..
> Gentoo is all about choice and choice is good.. But I dont want to have to
> go thourhg 800 use flags before I can install a gentoo system.. I used to
> be able to run ufed and set all of the use flags that I wanted for a
> system... I tried doing that yesterday.. the list has just gotten out of
> proportion.
> 

You don't have to; that's my point. Local USE flags are intended to 
allow very specific tweaking when you absolutely need it -- they're not 
intended to be something you go through and stick in make.conf on your 
original install. In fact, you probably shouldn't put them in make.conf 
-- they should probably be consistently used in package.use instead.

It's possible that the global USE flag list needs trimming. There are 
USE flags in there that should be probably be local, I'm sure.

-- 
Jon Portnoy
avenj/irc.freenode.net

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: [gentoo-web-user] Hardened PHP now in Gentoo

[Jon Portnoy]

On Wed, May 19, 2004 at 08:19:19PM +0200, Olivier Crete wrote:
> 
> The problem is that the current version of ufed just has all of the local
> use flags... It probably needs to be fixed... And we'd probably need to
> fix ufed and euse to put local use flags into package.use instead of
> make.conf...

Yep.

> But still, I dont really want ot have to enable every codec by hand when I
> compile any video related application...

I think we should address this with USE flag groupings. Someone should 
be able to just say they want full video support, for example, and that 
should enable all (freely available licensing-wise) codec flags. That 
way we can provide both simplicity and flexibility.

-- 
Jon Portnoy
avenj/irc.freenode.net

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: [gentoo-web-user] Hardened PHP now in Gentoo

[Ciaran McCreesh]

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

On Wed, 19 May 2004 14:34:12 -0400 Jon Portnoy <avenj@gentoo.org> wrote:
| I think we should address this with USE flag groupings. Someone should
| be able to just say they want full video support, for example, and
| that should enable all (freely available licensing-wise) codec flags.
| That way we can provide both simplicity and flexibility.

Strangely enough, I just suggested this in #gentoo-dev . Aside from the
issue of tidying up the existing USE flag setup, how do people feel
about something along the following lines (I'll GLEP it if the general
idea seems ok to people...):

ciaranm> jstubbs / genone: how hard would it be to add a use.groups to
portage which allowed aliases like @DESKTOP@ = @GNOME@ @KDE@ X, @GNOME@
= gtk2 gtk gnome X and @MEDIA@ = jpeg png dvd quicktime mpeg blah blah?

genone> ciaranm: shouldn't be too hard, but there might be some little
details I don't see atm making it difficult

ciaranm> genone: issues i could think of are recursive (would have to
avoid circular...), and behaviour of -@GNOME@ (i'd just ban that
outright...)

ciaranm> genone: presumably @GNOME@ -gtk2 (for example) would work...
right now USE="blah-blah" -> -blah, right?

genone> USE="bla -bla" => USE=""

ciaranm> and -blah blah -> blah?

genone> yep

ciaranm> cool, thanks

genone> circularity isn't a big problem, just limit to n levels of
dereference, -@GROUP@ shouldn't be a problem either

genone> I'm more thinking about orders and so

ciaranm> how would -@GROUP@ work? just invert all the flags in @GROUP@ ?

genone> yes

* ciaranm thinks that could get rather confusing

genone> why that ?

steel300> @GNOME@=-kde -qt gnome gtks

ciaranm> well, -@KDE@ for example would disable more than just kde

ciaranm> steel300: except then you'd upset people who do @KDE@ @GNOME@

ciaranm> steel300: i'd rather not have kde imply !gnome

genone> yeah, negated use flags would be forbidden in groups

steel300> it was just an example

ciaranm> steel300: i'm thinking @DESKTOP@=@KDE@ @GNOME@ @MEDIA@

ciaranm> for example

steel300> will any include -*?

genone> no

ciaranm> hell no

steel300> is this a user defined thing or do we manage it?

ciaranm> i'm not so sure about disabling -blah in groups... @SERVER@=-X
-kde -gnome -qt etc for example

ciaranm> steel300: i'd just stick it in /usr/portage/profiles/ myself...

ciaranm> steel300: mmmmmmmaybe allow an/etc/portage/ entry

genone> USE="-* @SERVER@"

Here's hoping -claws doesn't munge the formatting for once...

-- 
Ciaran McCreesh, Gentoo XMLcracy Member G03X276
(Sparc, MIPS, Vim, si hoc legere scis nimium eruditionis habes)
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-web-user] Hardened PHP now in Gentoo

[Allen Dale Parker]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Olivier Crete wrote:

|>On Wed, May 19, 2004 at 01:30:00PM +0200, foser wrote:
|>
|>>On Tue, 2004-05-18 at 21:08 +0100, Stuart Herbert wrote:
|>>Choice is an illusion, if you there's too much choice it is no use to
|>>anyone anymore, because nobody really knows what it is all about. This
|>>is already the case with the loads of USE flags/portage options/etc.
|>>we have. Gentoo shouldn't be about choice for the sake of it, it
|>>should be about simplicity/managability : stuff that works. It's a
|>>trade-off.
|>>
|>>I wasn't too happy with the introducation of local USE flags for just
|>>the reasons that are becoming a problem now. Too much flags, everybody
|>>adds them at will without good reasons. We used to just say to people
|>>who wanted a specific (rare) set-up that they could easily edit the
|>>ebuild themselves to their need, but nowadays it seems we have to hold
|>>hands all the time and add complexity for nothing. That's good for
|>>nobody really. The installation manual used to be like 5 pages, by now
|>>it's a book of it's own per arch. I don't think that's a good thing
|>>and we should be really, really careful about what we can do to stop
|>>this movement.
|>>
|>>- foser
|>
|>The users seem to be perfectly happy with having a maximum of choice
|>via  local USE flags. Most people are also okay with the handbook. So
|>what's  the problem, exactly? Should we force everyone to do what _you_
|>want  rather than what _they_ want?
|
|
| There is at least one other guy who thinks that the handbook has gotten
| way too long (me)...And foser is right on choice, too much is worst
that too little, because
| you end up not being able to find out howto where to configure stuff..
| Gentoo is all about choice and choice is good.. But I dont want to have to
| go thourhg 800 use flags before I can install a gentoo system.. I used to
| be able to run ufed and set all of the use flags that I wanted for a
| system... I tried doing that yesterday.. the list has just gotten out of
| proportion.
|

Would keeping global USE flags USE and swapping current local USE flags
over to local_USE solve any of these problems? I am also of the camp
that thinks that the amount of USE flags has gotten out of hand. My poor
router is a 1Ghz Via C3-2, originally installed with 1.4. When I first
bootstrapped that system, I had less than 10 USE flags in my make.conf.
I now have over 25 and yet MORE are being added on an almost daily basis
because my "old" USE flags just don't cut it anymore. I can't get the
features I want without adding 50 more USE flags and that's a little
ridiculous. I don't need a global USE flag for every multimedia codec
known to man. I've been wondering lately if the gentoo "server" project
has gotten anywhere, because MAYBE they've cut some of this cruft.

I don't mind editing ebuilds. I DO mind my make.conf splitting at the
seams. I DO mind my make.conf having a USE="---" that's about 3 lines
long wrapped at 1280x1024 (vga=0x31b). Gentoo is a great distribution,
because it does what I want it to when I want it to.

Instead of adding more USE flags for things that can be handled in other
ways (as per caleb's email), let's work on THINNING them down to a
reasonable level. If this means we need to make another USE type flag
definition, so be it. *BUT* when the gimp ebuilds haven't been touched
in almost a month (2.0.1 has been out since 04-17 and STILL isn't in
portage), other ebuilds are falling out of date, I'm SURE that we can
find more useful things to do than adding more USE flags.

- --
Allen Parker
GPG KeyID: 35544083
GPG FP: E628 7310 DE68 321A 933A  5DD1 C831 005C 3554 4083

infowolfe@irc.freenode.net #/tmp #gentoo-dev #gentoo-hardened
infowolfe@irc.oftc.net #vserver
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFAq5/TyDEAXDVUQIMRAtLeAJwLm1IiA09dYhR71Y/AlMMskNmDNgCfQ/WO
c/ZubD/1DQXCpGN4WXr9Ko4=
=53L9
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: [gentoo-web-user] Hardened PHP now in Gentoo

[Jon Portnoy]

On Wed, May 19, 2004 at 01:56:35PM -0400, Allen Dale Parker wrote:
> definition, so be it. *BUT* when the gimp ebuilds haven't been touched
> in almost a month (2.0.1 has been out since 04-17 and STILL isn't in
> portage), other ebuilds are falling out of date, I'm SURE that we can
> find more useful things to do than adding more USE flags.
> 

Frankly the reason GIMP gets out of date, among other gnome herd 
packages, is that the GNOME herd seems to want to retain maintainership 
of a lot of packages totally irrelevant to GNOME proper without having 
enough manpower to deal with it.

Regarding make.conf: look into package.use. `man portage` in the 
/etc/portage section.

-- 
Jon Portnoy
avenj/irc.freenode.net

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: [gentoo-web-user] Hardened PHP now in Gentoo

[Allen Dale Parker]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jon Portnoy wrote:

| On Wed, May 19, 2004 at 01:56:35PM -0400, Allen Dale Parker wrote:
|
|>definition, so be it. *BUT* when the gimp ebuilds haven't been touched
|>in almost a month (2.0.1 has been out since 04-17 and STILL isn't in
|>portage), other ebuilds are falling out of date, I'm SURE that we can
|>find more useful things to do than adding more USE flags.
|>
|
|
| Frankly the reason GIMP gets out of date, among other gnome herd
| packages, is that the GNOME herd seems to want to retain maintainership
| of a lot of packages totally irrelevant to GNOME proper without having
| enough manpower to deal with it.
|
| Regarding make.conf: look into package.use. `man portage` in the
| /etc/portage section.
|

So how exactly does one tell between local/global USE flags with emerge
- -pv? Or is there some tool that I'm not aware of (other than ufed) that
will help me figure out what applies to what package? It certainly seems
like quite a few hoops to jump through just to get my systems to run the
way they did under 1.4. (on my dual-booting desktop, package.keywords
has around 30 entries in /etc/portage/package.keywords) Basically, it
seems that the dilema is that more USE flag cruft is being added to what
once was a pretty slim and sleak distro. Oh, my last word on this issue:
/etc/portage/package.use seems like a good idea until it's ~300 lines
(assuming I find the time to actually parse the USE flags available for
each of the packages *and their dependancies* that I use on a
semi-regular basis).

In regards to the GNOME herd being overloaded: is there a way to
collectively slap them and let them know that they need to just *let go*
and pick a core set of packages to maintain? (gimp seems like it'd be
pretty important/popular)

It just seems from this perspective adding more USE flags means more
work for already stressed out and overworked devs.

Another idea for a solution to this mess is to *seperate* features into
classes: ie, if you're running X11, you'd have the desktop class of
local USE flags to choose from, etc. Adds a bit of complexity on the
backend, but would probably simplify a lot of things for people that
don't run X11 on all of their systems. I'd probably run <server -java>
or <console -java> and be a happy boy because X11 and things depending
on X11 would be masked by default for my particular machine-class.

- --
Allen Parker
GPG KeyID: 35544083
GPG FP: E628 7310 DE68 321A 933A  5DD1 C831 005C 3554 4083

infowolfe@irc.freenode.net #/tmp #gentoo-dev #gentoo-hardened
infowolfe@irc.oftc.net #vserver
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFAq6ZSyDEAXDVUQIMRAlvyAJ0SOp3rhyq+HV+/yPpDAH8Kxr48CQCfUMEb
4A0ji1vM+2RBpvcRVajO0FA=
=a6rq
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: [gentoo-web-user] Hardened PHP now in Gentoo

[foser]

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

On Wed, 2004-05-19 at 14:01 -0400, Jon Portnoy wrote:
> On Wed, May 19, 2004 at 01:56:35PM -0400, Allen Dale Parker wrote:
> > definition, so be it. *BUT* when the gimp ebuilds haven't been touched
> > in almost a month (2.0.1 has been out since 04-17 and STILL isn't in
> > portage), other ebuilds are falling out of date, I'm SURE that we can
> > find more useful things to do than adding more USE flags.
> > 
> 
> Frankly the reason GIMP gets out of date, among other gnome herd 
> packages, is that the GNOME herd seems to want to retain maintainership 
> of a lot of packages totally irrelevant to GNOME proper without having 
> enough manpower to deal with it.

A totally irrelevant point in this thread, but I suppose one has to
grasp that one minute of attention and use it to its full extent.

The gimp has been over time (even in the 1.3 series) maintained
perfectly fine. Due to some seriously uncontrolled developer
unavailability it has suffered a bit lately. Gnome held on to Gimp
maintainership for mainly two reasons. First Gimp is _the_ gtk+ example
application and second because frankly the changes made over time by
non-gnome team members have all been regressions or failures to
understand it's underlying structure. We do hand over packages to other
teams (gladly mostly), but we do want it to be maintained at least as
well as it was done before (in quality). Previous experiences have made
us wary of that and then we get to clean up the mess and we double our
workload unlike when we would've handled it ourselves in the first
place. Sounds arrogant ? Guess so, but if we're getting frank I'm gonna
be frank as well.

- foser

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

[gentoo-dev] Local USE Flags and Gentoo Handbook (was: Re: Hardened PHP now in Gentoo)

[Octavio Ruiz (Ta^3)]

Olivier Crete, who happens to be smarter than you, thinks:
> > The users seem to be perfectly happy with having a maximum of choice
> > via  local USE flags. Most people are also okay with the handbook. So
> > what's  the problem, exactly? Should we force everyone to do what _you_
> > want  rather than what _they_ want?
> 
> There is at least one other guy who thinks that the handbook has gotten
> way too long (me)...And foser is right on choice, too much is worst that too little, because
> you end up not being able to find out howto where to configure stuff..

What about http://www.gentoo.org/doc/en/gentoo-x86-quickinstall.xml ?

> Gentoo is all about choice and choice is good.. But I dont want to have to
> go thourhg 800 use flags before I can install a gentoo system.. I used to
> be able to run ufed and set all of the use flags that I wanted for a
> system... I tried doing that yesterday.. the list has just gotten out of
> proportion.

The particular problem IMHO with local USE flags is that we have a lot of "local
USE flags" than can be a global USE flag. Many ebuilds have similiar local
USE flags with diferent name and do the same thing. Or maybe not making it
global but make it consistent.

-- 
Have a nice diurnal anomaly.

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: [gentoo-web-user] Hardened PHP now in Gentoo

[oford]

On Wed, 19 May 2004 19:26:34 +0200 (CEST)
Olivier Crete <tester@gentoo.org> wrote:

> There is at least one other guy who thinks that the handbook has gotten
> way too long (me)...And foser is right on choice, too much is worst that too little, because
> you end up not being able to find out howto where to configure stuff..
> Gentoo is all about choice and choice is good.. But I dont want to have to
> go thourhg 800 use flags before I can install a gentoo system.. I used to
> be able to run ufed and set all of the use flags that I wanted for a
> system... I tried doing that yesterday.. the list has just gotten out of
> proportion.

I happen to agree that the list is too cumbersome and long. So why not sort them into categories ie use.local.media use.local.kde etc.

As someone earlier mentioned the kernel's .config, why not have ufed work more like menuconfig and have submenus based on what is affected by toggling the USE flag?  That makes it so much faster to find what you need.  The alphabetical sort is tedious to dig through just to find one lousy flag.  I tend to give up before I find it (or to not use ufed at all).

--owen

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: [gentoo-web-user] Hardened PHP now in Gentoo

[Caleb Tennis]

On Wednesday 19 May 2004 11:06 am, Jon Portnoy wrote:
> The users seem to be perfectly happy with having a maximum of choice via
> local USE flags. Most people are also okay with the handbook. So what's
> the problem, exactly? Should we force everyone to do what _you_ want
> rather than what _they_ want?

Count me as a second "user", who along with foser, believes there are too many 
local use flags.

In particular, it seems like a lot of packages could be compiled without the 
need for the flags - if later a user decides they want the "added 
functionality", all it requires is an emerge of the "added functionality" 
package, then a re-emerge of the original.

That is, instead of using use flags to pull in some optional deps, let the 
ebuild figure out what to configure based on what's already installed.

An example: there's a bug report open now about how a user emerged "kdesdk" 
and it didn't compile cervisia because they didn't have cvs installed 
already.  They're requesting a local use flag for this.  I'm more inclined 
just to say "emerge cvs kdesdk" will fix the problem, because it saves one 
more local use flag for something which is rather easily fixed.

This is a sensitive topic for me, because if I added local use flags for 
"customizable" things you could do with the kde ebuilds, we'd probably have 
at least 50 more flags in the space.  I sure would like to avoid that.

I would say that at ~600 use flags, the space is starting to get a bit 
polluted.  Having a dialogue now about how to handle it is a good thing.

Caleb

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: [gentoo-web-user] Hardened PHP now in Gentoo

[Ciaran McCreesh]

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

On Wed, 19 May 2004 12:44:15 -0500 Caleb Tennis <caleb@gentoo.org>
wrote:
| In particular, it seems like a lot of packages could be compiled
| without the need for the flags - if later a user decides they want the
| "added functionality", all it requires is an emerge of the "added
| functionality" package, then a re-emerge of the original.

I suggest you start running *now*, before Spider catches you and eats
you alive.

| That is, instead of using use flags to pull in some optional deps, let
| the ebuild figure out what to configure based on what's already
| installed.

We've had this discussion over and over again. It's an extremely bad
idea to do things this way. It will break stages. It will break livecds.
It will break GRP. It will cause extremely confusing and inconsistent
behaviour. It will *not* make things simpler for the end user -- instead
of having to set a few USE flags, they have to come up with complex
emerge commands figuring out some magic to do with install order.

| An example: there's a bug report open now about how a user emerged
| "kdesdk" and it didn't compile cervisia because they didn't have cvs
| installed already.  They're requesting a local use flag for this.  I'm
| more inclined just to say "emerge cvs kdesdk" will fix the problem,
| because it saves one more local use flag for something which is rather
| easily fixed.

Uh, no. That is not an acceptable fix for the bug.

-- 
Ciaran McCreesh, Gentoo XMLcracy Member G03X276
(Sparc, MIPS, Vim, si hoc legere scis nimium eruditionis habes)
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-web-user] Hardened PHP now in Gentoo

[Caleb Tennis]

On Wednesday 19 May 2004 12:57 pm, Ciaran McCreesh wrote:
> | That is, instead of using use flags to pull in some optional deps, let
> | the ebuild figure out what to configure based on what's already
> | installed.
>
> We've had this discussion over and over again. It's an extremely bad
> idea to do things this way.

I'm not saying it's a one size fits all scenario, nor am I suggesting we 
remove use flags entirely.  I'm suggesting that we can trim them down, 
perhaps move a lot of global flags to local flags as was suggested, and still 
present just as much "choice".

> | An example: there's a bug report open now about how a user emerged
> | "kdesdk" and it didn't compile cervisia because they didn't have cvs
> | installed already.  They're requesting a local use flag for this.  I'm
> | more inclined just to say "emerge cvs kdesdk" will fix the problem,
> | because it saves one more local use flag for something which is rather
> | easily fixed.
>
> Uh, no. That is not an acceptable fix for the bug.

Then it will get closed as LATER, as I'm the one doing the work, and until 
someone else comes along who has a contrasting opinion, and wants to 
implement all of the use flags, it won't get "fixed".  After all, isn't a 
significant portion of the contributions to portage based on developer 
opinion of the "best" way of doing things?

Look, users can still edit ebuilds, and can still run things in their 
overlays.  Even if we were to remove some of the use flags, and provide a way 
within an ebuild to "quickly edit" things to their choosing, how is that 
taking away choice?  It's not: it's shifting the burden of choice to the user 
who wants it, instead of putting the burden of choice on all of the users.

I'm not suggesting the above is a good way of doing things - it's purely for 
example.  Personally, I'm fairly open minded about the topic, and I hope 
those on the other side of the argument are as well.

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] USE flag explosion

[Jason Stubbs]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thursday 20 May 2004 02:44, Caleb Tennis wrote:
> In particular, it seems like a lot of packages could be compiled without
> the need for the flags - if later a user decides they want the "added
> functionality", all it requires is an emerge of the "added functionality"
> package, then a re-emerge of the original.
>
> That is, instead of using use flags to pull in some optional deps, let the
> ebuild figure out what to configure based on what's already installed.

I think you mean let the configure script figure it out... I'm against that as 
things stand now due to the reasons that Ciaran mentioned. However...

If there was a new type of depend atom that meant "use it if it's installed" 
and emerge had a convenient way of force-installing such deps, I think both 
sides would be happy.

When creating binaries or installing packages, portage can mangle the deps so 
that this type of dep becomes a regular dep or is removed altogether. This 
would also get around the many broken configure scripts that use other 
packages even when you specify --without.

Regards,
Jason Stubbs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iQCVAwUBQKwN8FoikN4/5jfsAQIt/QP/avvnpEEOR0HbHARpbFp8dB7o6Pcj/0co
C0IGfG+JI3KJbddkQbcIBc+WNUMLqXdV2I/Q0ViQsgmHoUnJWUnHhLhrXjZQcDU0
p5q8gmeGME4g7aAbcx5MubtDL5kij5aCw9X3Ezsi8A0XCKBh+crPVOyknROtNeHk
SgwF8K4Rjds=
=e86Q
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: [gentoo-web-user] Hardened PHP now in Gentoo

[Georgi Georgiev]

maillog: 19/05/2004-12:44:15(-0500): Caleb Tennis types
> In particular, it seems like a lot of packages could be compiled without the 
> need for the flags - if later a user decides they want the "added 
> functionality", all it requires is an emerge of the "added functionality" 
> package, then a re-emerge of the original.
> 
> That is, instead of using use flags to pull in some optional deps, let the 
> ebuild figure out what to configure based on what's already installed.

Weren't USE flags that bear the name of a package being set, depending on
whether the package is installed or not, unless specifically set in one of the
config files? I.e., unless you say "USE=gimp" or "USE=-gimp", then a gimp use
flag would be set only if you have gimp installed.

-- 
 /   Georgi Georgiev    / "If there isn't a population problem, why is  /
\     chutz@gg3.net    \  the government putting cancer in the         \
 /  +81(90)6266-1163    / cigarettes?" -- the elder Steptoe, c. 1970    /

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: [gentoo-web-user] Hardened PHP now in Gentoo

[Stuart Herbert]

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

On Wednesday 19 May 2004 12:30, foser wrote:
> The second time you mention choice. I guess we know what Gentoo is about
> by now, the 'choice' argument is too often used just to end criticism.

If people are arguing against additional choice, then I guess that at least 
some devs don't get that this is an important part of Gentoo.

> Choice is an illusion, 

Try telling that to people using <insert distro here> who don't have that 
choice.

> if you there's too much choice it is no use to 
> anyone anymore, because nobody really knows what it is all about. 

Agreed.  So is the problem choice itself, or the tools we use to deliver that 
choice to our users?

> This 
> is already the case with the loads of USE flags/portage options/etc. we
> have. Gentoo shouldn't be about choice for the sake of it, it should be
> about simplicity/managability : stuff that works. It's a trade-off.

Where do we have choice for the sake of it?

Reducing choice does not always increase simplicity.

> I wasn't too happy with the introducation of local USE flags for just
> the reasons that are becoming a problem now. Too much flags, everybody
> adds them at will without good reasons. 

USE flags allow users to switch on (and off I guess) optional settings.

What would you prefer?

a) hardened-php patch not available at all in Gentoo
b) hardened-php patch always included

Because those are the only choices you are leaving.

> We used to just say to people 
> who wanted a specific (rare) set-up that they could easily edit the
> ebuild themselves to their need, 

Thank god we don't do that any more!  I'm all for educating our users in the 
ways of UNIX-like systems, but perhaps that is raising the bar too high.

> but nowadays it seems we have to hold 
> hands all the time and add complexity for nothing. 

I don't think USE flags are hand-holding.  The principle - that a Gentoo dev 
spends a little time working out how to safely make an optional feature 
available - scales far better than expecting all of our users to try and 
solve the same problem for themselves all the time.

> That's good for 
> nobody really. 

I agree that adding complexity is not good.

> The installation manual used to be like 5 pages, by now 
> it's a book of it's own per arch. I don't think that's a good thing and
> we should be really, really careful about what we can do to stop this
> movement.

The installation manual used to cover just one architecture.

I'm sure our users appreciate the vast improvements that the handbook 
contributors have delivered since those early days.

> You have the choice. The real power is the easy way in which you can
> adapt it to your needs and the simplicity of doing so. 

Which is exactly what USE flags currently provide - until someone figures out 
a better way to deliver the same amount of choice.

> Huge loads of nobody-ever-uses them options don't help one bit.

Just because you don't use them, don't assume that no-one else finds them 
useful.

> You should keep it basic for exactly the reason that anyone can adapt 
> it easily. Adding layers of complexity leads to a system that needs 
> time & effort to get into : you lose what you want, you lose the true 
> power.

The simplicity has to be at the point of use.  The major point of use for our 
users is the 'emerge' command.  If USE flags are too complicated, why not 
suggest something better?  I'm not sure that eliminating choice is something 
better.

> The defaults should be good enough, all the extra stuff is mostly cruft 
> in 99.9% of the cases. 

I agree that the defaults should at least be sensible.  But I don't agree that 
the optional stuff is cruft.  You may not need some of these options, but 
there are users out there who are.

As long as there are developers willing to maintain these optional features, 
why is offering choice (as a principle) wrong?

> That cruft therefore isn't necessary in the distro, keeping the 
> playing field clean and open.

I'm *soooo* glad that everyone doesn't agree with that statement.

You want to take a distribution that provides a tonne of flexibility - more 
than any of the competition - and see all that flexibility removed from it?  
Is that really your position?

> We're creating tools to be able to work with our tools, thats in indication
> of going the wrong way. 

Then what is the right way to deliver the richness that is Gentoo *without* 
losing the flexibility that others like (even if you don't seem to)?

I guess I've mentioned choice a lot more than twice by now :)

Best regards,
Stu
-- 
Stuart Herbert                                              stuart@gentoo.org
Gentoo Developer                                       http://www.gentoo.org/
                                                   http://stu.gnqs.org/diary/

GnuPG key id# F9AFC57C available from http://pgp.mit.edu
Key fingerprint = 31FB 50D4 1F88 E227 F319  C549 0C2F 80BA F9AF C57C
--

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

Re: [gentoo-dev] Re: [gentoo-web-user] Hardened PHP now in Gentoo

[Joshua Brindle]

*sigh* this thread is already out of control but all the hardened devs 
agree with the use of the hardened flag. It wouldn't take choice away, 
anyone that ways hardened-php without the other hardened stuff can use 
/etc/portage/ .. that is why it's there, to help advanced users select 
use flags more granularly..

Stuart Herbert wrote:
> On Wednesday 19 May 2004 12:30, foser wrote:
> 
>>The second time you mention choice. I guess we know what Gentoo is about
>>by now, the 'choice' argument is too often used just to end criticism.
> 
> 
> If people are arguing against additional choice, then I guess that at least 
> some devs don't get that this is an important part of Gentoo.
> 
You are confusing choice with excessive work, having 500 use flags *does 
not* help the choice cause, it increases work and therby decreases choice.

<snip>
> 
> Where do we have choice for the sake of it?
> 
> Reducing choice does not always increase simplicity.
> 
> 
heh, you name it :) but again, additional use flags *does not* equal 
more choice, there is a delicate balance

>>I wasn't too happy with the introducation of local USE flags for just
>>the reasons that are becoming a problem now. Too much flags, everybody
>>adds them at will without good reasons. 
> 
> 
> USE flags allow users to switch on (and off I guess) optional settings.
> 
> What would you prefer?
> 
> a) hardened-php patch not available at all in Gentoo
> b) hardened-php patch always included
> 
> Because those are the only choices you are leaving.
> 
that couldn't be more incorrect, check top point

> 
> The installation manual used to cover just one architecture.
> 
> I'm sure our users appreciate the vast improvements that the handbook 
> contributors have delivered since those early days.
> 
> 
>>You have the choice. The real power is the easy way in which you can
>>adapt it to your needs and the simplicity of doing so. 
> 
> 
> Which is exactly what USE flags currently provide - until someone figures out 
> a better way to deliver the same amount of choice.
> 
> 
>>Huge loads of nobody-ever-uses them options don't help one bit.
> 
> 
> Just because you don't use them, don't assume that no-one else finds them 
> useful.
> 
But we can't help 100% of people, we can help the majority, anything 
more is more work for us, and more work for the vast majority of users.

why should 90-95% of the users have to sift through hundreds of use 
flags that 5-10% of users use? It doesn't make sense.

<snip>

There are more things that gentoo offers than choice, just yesterday 
Stuart and I had a conversation about webapp-config and how convenient 
that is, and how other distros don't use it. We offer innovation and 
easy system administration. Choice is a primary concern but not that the 
expense of everything else, please keep this in mind.

Joshua Brindle

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: [gentoo-web-user] Hardened PHP now in Gentoo

[Jon Portnoy]

On Wed, May 19, 2004 at 01:41:01PM -0500, Joshua Brindle wrote:
> *sigh* this thread is already out of control but all the hardened devs 
> agree with the use of the hardened flag. It wouldn't take choice away, 
> anyone that ways hardened-php without the other hardened stuff can use 
> /etc/portage/ .. that is why it's there, to help advanced users select 
> use flags more granularly..
> 
> Stuart Herbert wrote:
> >On Wednesday 19 May 2004 12:30, foser wrote:
> >
> >>The second time you mention choice. I guess we know what Gentoo is about
> >>by now, the 'choice' argument is too often used just to end criticism.
> >
> >
> >If people are arguing against additional choice, then I guess that at 
> >least some devs don't get that this is an important part of Gentoo.
> >
> You are confusing choice with excessive work, having 500 use flags *does 
> not* help the choice cause, it increases work and therby decreases choice.
> 

Can you explain the logical connection between "increases work" and 
"decreases choice"?

> <snip>
> >
> >Where do we have choice for the sake of it?
> >
> >Reducing choice does not always increase simplicity.
> >
> >
> heh, you name it :) but again, additional use flags *does not* equal 
> more choice, there is a delicate balance

How so?

> But we can't help 100% of people, we can help the majority, anything 
> more is more work for us, and more work for the vast majority of users.
> 
> why should 90-95% of the users have to sift through hundreds of use 
> flags that 5-10% of users use? It doesn't make sense.

See the rest of the discussion, particularly about people *not* having 
to sift through hundreds of USE flags if ufed was fixed, and also the 
fact that USE flag grouping can fix the ballooning global flags issue.


-- 
Jon Portnoy
avenj/irc.freenode.net

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: [gentoo-web-user] Hardened PHP now in Gentoo

[foser]

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

On Wed, 2004-05-19 at 14:48 -0400, Jon Portnoy wrote:
> See the rest of the discussion, particularly about people *not* having 
> to sift through hundreds of USE flags if ufed was fixed, and also the 
> fact that USE flag grouping can fix the ballooning global flags issue.

USE flag grouping still is basic step from what we have now, not a
re-evalution. Don't fail to realize that USE flags at this point
represent a lot of different concepts and that mere grouping is a
temporary hack, not a solution.

Ufed : tools to use tools. This whole discussion somehow got focused on
USE flags, but it is much broader than that. It's more the concept that
added complexity decreases control on an individual level.

Most people used to be drawn to Gentoo because of it's adaptability, but
we're losing that to adding cruft for rare use case scenario's. Portage
gets more and more obscure features, while basic stuff like normal dep
tracking is still lacking and there are a few half finished concepts
lying around (like SLOTs) that still need fixing.
Focus has been on the wrong areas, rarely used niceties over a solid
basic framework. A building is as strong as it's base.

- foser

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

Re: [gentoo-dev] Re: [gentoo-web-user] Hardened PHP now in Gentoo

[Stuart Herbert]

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

On Wednesday 19 May 2004 19:41, Joshua Brindle wrote:
> *sigh* this thread is already out of control

I do admit, I am a bit surprised that such a small patch to a package that 
many Gentoo devs openly prefer not to use anyway (and such is their right ;-) 
has caused such fuss.

I was hoping that people would be happy that we're adding a bit of value, and 
perhaps doing a little bit more in the web-serving area than the other 
distributions.  Maybe that was unrealistic ;-)

> but all the hardened devs agree with the use of the hardened flag.

Sorry, but I don't.  I'm sympathetic, and agree that USE flags shouldn't be 
added for the sake of it.  But I believe that the 'hardened' USE flag is for 
a different feature.  Combining the two does not make sense to me.

I'm not going to do it.

> It wouldn't take choice away, 
> anyone that ways hardened-php without the other hardened stuff can use
> /etc/portage/ .. that is why it's there, to help advanced users select
> use flags more granularly..

It's great that Portage can be so flexible, but tbh in this case I think 
having to resort to entries in /etc/portage just supports the idea that 
"hardened" and "hardenedphp" are actually two different things.

> You are confusing choice with excessive work, having 500 use flags *does
> not* help the choice cause, it increases work and therby decreases choice.

Then let's invent a better mechanism to deliver this choice.  Let's get a 
discussion going on *how* to deliver this choice, and then let's deliver 
better tools.

Right now, though, we seem to be debating whether or not we should be offering 
the choice at all.  Is that topic on the table or not?

We've got ~8300 packages, and ~600 USE flags.  Just over 200 of those flags 
are global, leaving just under 400 local flags.  That compares with 941 
CONFIG settings in /usr/src/linux-2.6.6/.config on this box.

> But we can't help 100% of people, we can help the majority, anything
> more is more work for us, and more work for the vast majority of users.

No-one is forcing you to add USE flags to your packages.

> why should 90-95% of the users have to sift through hundreds of use
> flags that 5-10% of users use? It doesn't make sense.

Okay - let's look at that objectively, and see how we can craft a better 
solution.  I'm offering to write the result up as a GLEP, and if necessary to 
code it too.

Anyone want to make a start?

> <snip>
>
> There are more things that gentoo offers than choice, just yesterday
> Stuart and I had a conversation about webapp-config and how convenient
> that is, and how other distros don't use it. 

The whole GLEP 11 initiative came out of a discussion on how we could better 
deliver choice.  We wanted a way to support more than just the one web 
server, and to support both virtual hosting and non-virtual hosting too.

Working together, we've delivered on part of that.

> We offer innovation and easy system administration. 

The ability to tailor the package - without having to compile the damn thing 
by hand - is an integral part of that easy system administration.

> Choice is a primary concern but not that the expense of everything else,
> please keep this in mind. 

I agree it shouldn't be at the expense of everything else.

Let's reduce this thread down to looking at how we can better deliver the 
choice.  Let's design a better tool.

Best regards,
Stu
-- 
Stuart Herbert                                              stuart@gentoo.org
Gentoo Developer                                       http://www.gentoo.org/
                                                   http://stu.gnqs.org/diary/

GnuPG key id# F9AFC57C available from http://pgp.mit.edu
Key fingerprint = 31FB 50D4 1F88 E227 F319  C549 0C2F 80BA F9AF C57C
--

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

Re: [gentoo-dev] Hardened PHP now in Gentoo

[Chris PeBenito]

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

On Wed, 2004-05-19 at 18:23, Tom Payne wrote:
> On Wed, May 19, 2004 at 08:52:02PM +0100, Stuart Herbert wrote:
> > Sorry, but I don't.  I'm sympathetic, and agree that USE flags shouldn't be 
> > added for the sake of it.  But I believe that the 'hardened' USE flag is for 
> > a different feature.  Combining the two does not make sense to me.
> > 
> > I'm not going to do it.

> hardened Gentoo meaning stack overflow protection, toolchain mods, etc. etc.
> is different to harder-to-exploit PHP. Hardened PHP (AIUI) is more like Safe
> mode in Ruby (and other scripting languages). The two are different things
> and should not be confused.

No, it means the same thing.  From the hardened php site:

Implemented protections (until now)

- Canary protection of the Zend Memory Manager
- Canary protection of Zend Linked Lists
- Protection against internal format string exploits
- Protection against arbitrary code inclusion
- Syslog logging of attackers IP

The first four are all hardened-like things, a la PaX, PIE, and SSP.

-- 
Chris PeBenito
<pebenito@gentoo.org>
Developer,
Hardened Gentoo Linux
Embedded Gentoo Linux
 
Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE6AF9243
Key fingerprint = B0E6 877A 883F A57A 8E6A  CB00 BC8E E42D E6AF 9243

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

Re: [gentoo-dev] Hardened PHP now in Gentoo

[Tom Payne]

On Wed, May 19, 2004 at 06:49:12PM -0500, Chris PeBenito wrote:
> On Wed, 2004-05-19 at 18:23, Tom Payne wrote:
> > hardened Gentoo meaning stack overflow protection, toolchain mods, etc. etc.
> > is different to harder-to-exploit PHP. Hardened PHP (AIUI) is more like Safe
> > mode in Ruby (and other scripting languages). The two are different things
> > and should not be confused.
> 
> No, it means the same thing.  From the hardened php site:

Ooops, my bad. Thanks for the clarification. I guess I'm trying to work out
"if I want hardened gentoo, do I always want hardened php?" and vice versa,
as would be implied by the two having the same USE flag. To me, hardening
the system vs. hardening a web scripting language are two separate things
(i.e. you could want one without the other) but I haven't yet come up with a
convincing argument for this :-)

-- 
Tom

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Hardened PHP now in Gentoo

[Max Kalika]

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

Quoting Tom Payne <twp@gentoo.org>:

> Ooops, my bad. Thanks for the clarification. I guess I'm trying to work
> out "if I want hardened gentoo, do I always want hardened php?" and vice
> versa, as would be implied by the two having the same USE flag. To me,
> hardening the system vs. hardening a web scripting language are two
> separate things (i.e. you could want one without the other) but I haven't
> yet come up with a convincing argument for this :-)

It's not too different than saying "do I want ssl support in postfix and
not in php?"  In either case, if you want a certain package to disable a
global USE flag, just plop the following into /etc/portage/package.use

  >=dev-php/php-4*     -hardened

-- 
max kalika
 .. public key:   http://www.gentoo.org/~max/max.asc
 .. fingerprint:  2D59 74B5 8785 3C22 74F2 87B0 6DD4 E810 CBC3 AB79

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

Re: [gentoo-dev] Hardened PHP now in Gentoo

[Carsten Lohrke]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thursday 20 May 2004 02:02, Tom Payne wrote:

> I guess I'm trying to work out 
> "if I want hardened gentoo, do I always want hardened php?" and vice versa,
> as would be implied by the two having the same USE flag.
I thought that's why package.use exist; To change the default behaviour of a 
particular ebuild. I won't damn local use flags, but I'm not fine with the 
current status, too. And even if the functionality is not the same, if the 
idea behind it is, why not reusing a flag?


Carsten
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAq/51VwbzmvGLSW8RAoHVAJ9uyJx7zOY820gI1H7RKsnSdJZELwCbBlJB
TMd7PuV3C5mRIwgRL4F+vzY=
=Fmrg
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: [gentoo-web-user] Hardened PHP now in Gentoo

[John Nilsson]

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

On Wed, 2004-05-19 at 21:52, Stuart Herbert wrote:
> Let's reduce this thread down to looking at how we can better deliver the 
> choice.  Let's design a better tool.
> 
> Best regards,
> Stu

Why not drop global USE-flags and adopt the kernel configuration system?

-John



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

Re: [gentoo-dev] Re: [gentoo-web-user] Hardened PHP now in Gentoo

[Troels Vognsen]

>On Wed, May 19, 2004 at 01:30:00PM +0200, foser wrote:
>> On Tue, 2004-05-18 at 21:08 +0100, Stuart Herbert wrote:
>> 
>> > I'm pro-choice, and do not agree with the idea of aggregating USE flags just 
>> > because they sound similar.
>> 
>> The second time you mention choice. I guess we know what Gentoo is about
>> by now, the 'choice' argument is too often used just to end criticism.
>> 
>> Choice is an illusion, if you there's too much choice it is no use to
>> anyone anymore, because nobody really knows what it is all about. This
>> is already the case with the loads of USE flags/portage options/etc. we
>> have. Gentoo shouldn't be about choice for the sake of it, it should be
>> about simplicity/managability : stuff that works. It's a trade-off.
>> 
>> I wasn't too happy with the introducation of local USE flags for just
>> the reasons that are becoming a problem now. Too much flags, everybody
>> adds them at will without good reasons. We used to just say to people
>> who wanted a specific (rare) set-up that they could easily edit the
>> ebuild themselves to their need, but nowadays it seems we have to hold
>> hands all the time and add complexity for nothing. That's good for
>> nobody really. The installation manual used to be like 5 pages, by now
>> it's a book of it's own per arch. I don't think that's a good thing and
>> we should be really, really careful about what we can do to stop this
>> movement.
>> 
>> - foser
>
>The users seem to be perfectly happy with having a maximum of choice via 
>local USE flags. Most people are also okay with the handbook. So what's 
>the problem, exactly? Should we force everyone to do what _you_ want 
>rather than what _they_ want?
>
>-- 
>Jon Portnoy
>
Well, I believe that there's nothing wrong with *providing* choice - it will only ruin useability when you *require* it.  Good default values will ensure that the average user ain't forced to make decisions right away.
But ofcourse choices must be sanely organised. Finding and changing options should be intuitive.
For instance I use ufed to change my use flags. That's fairly intuitive, but due to the amount of local flags it can be slightly confusing. That could however be fixed by hiding the local flags by default, and provide the choice of including them (by means of a command line option or so).
In this case choice aids both simplicity and useability. As another example think of ls. It has well over 30 options. But that doesn't ruin useability, because it by default behaves as I would expect it to do, without having read the entire man page. Likewise use flags won't ruin gentoo's useability as long as they are sanely organised.
Simplifying my own statement, I think useability is genrally inverse-proportional to the amount of choices the user is forced to make, to archive a given task.

Just my 2 cents,
- Troels Vognsen


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: [gentoo-web-user] Hardened PHP now in Gentoo

[Troels Vognsen]

From: Olivier Crete <tester@gentoo.org>
>There is at least one other guy who thinks that the handbook has gotten
>way too long (me)...And foser is right on choice, too much is worst that too little, because
>you end up not being able to find out howto where to configure stuff..
>Gentoo is all about choice and choice is good.. But I dont want to have to
>go thourhg 800 use flags before I can install a gentoo system.. I used to
>be able to run ufed and set all of the use flags that I wanted for a
>system... I tried doing that yesterday.. the list has just gotten out of
>proportion.
>
>Olivier Crete
>
Well, ain't that mainly an issue of layout change. If we split the body's of text into smaller sections and colorcode them appropriately, according the type of information and significance, that would improve readabilty significantly. I could hence read through the handbook, reading only the (for instance) green sections, skipping the rest, since I know that ain't vital info.

- Troels Vognsen :-)


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: [gentoo-web-user] Hardened PHP now in Gentoo

[Olivier Crete]

 On Wed, May 19, 2004 at 07:26:34PM +0200, Olivier Crete wrote:
>>
>> There is at least one other guy who thinks that the handbook has
>> gotten way too long (me)...And foser is right on choice, too much is
>> worst that too little, because you end up not being able to find out
>> howto where to configure stuff.. Gentoo is all about choice and choice
>> is good.. But I dont want to have to go thourhg 800 use flags before I
>> can install a gentoo system.. I used to be able to run ufed and set
>> all of the use flags that I wanted for a system... I tried doing that
>> yesterday.. the list has just gotten out of proportion.
>>
>
> You don't have to; that's my point. Local USE flags are intended to
> allow very specific tweaking when you absolutely need it -- they're not
>  intended to be something you go through and stick in make.conf on your
>  original install. In fact, you probably shouldn't put them in
> make.conf  -- they should probably be consistently used in package.use
> instead.

The problem is that the current version of ufed just has all of the local
use flags... It probably needs to be fixed... And we'd probably need to
fix ufed and euse to put local use flags into package.use instead of
make.conf...

But still, I dont really want ot have to enable every codec by hand when
compile any video related application...
-- 

Olivier Crete
tester@gentoo.org



--
gentoo-dev@gentoo.org mailing list