Re: [gentoo-dev] Some numbers

[foser <foser@gentoo.org>]

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