Re: [gentoo-dev] Default Ebuild behaviour

[Ciaran McCreesh]

On Tue, 31 Jan 2006 17:06:35 +0000 "Benjamin Smee (strerror)"
<strerror@g.o> wrote:
| On Tuesday 31 January 2006 15:47, Ciaran McCreesh wrote:
| > | What is the "cost" you are referring to specifically? I think I
| > | know but I'd like a specific definition.
| >
| > 1. Management. For example, handling etc-update.
| 
| That is surely a "cost" people have for upgrading an application and
| have implicitly accepted by doing so.

Not really. There's a basic cost of installing or upgrading an
application, but there's also additional cost that comes from optional
extras.

| > 3. Performance. Entries in /etc can have a serious performance
| > impact. The easy example is bash completion, which can be
| > reaaallllly slow if you have a few hundred entries.
| 
| I find this hard to swallow. You could say that about any directory
| that is over a certain size, say typically /dev. Thats even on the
| assumption that most people use bash completion constantly or that on
| modern hardware it is a noticeable problem, which in my experience is
| not the case.

Noooooo! Not the cost from using a sucky filesystem. The cost from your
application of choice having to parse all those files. Bash is a good
example -- it's not particularly fast (read: very slow) at parsing
scripts, and if you have a zillion bash completion scripts installed
then something as simple as starting a terminal can take a very long
time. It's precisely this that lead to bash-completion-config.

| Then change the default configuration so that it only updates for the 
| directories that you want. The expectation that a package works after
| an emerge is in 99% of cases perfectly reasonable, and if its not
| perfect for one persons particular environment then the onus is on
| them to fix it. We can't be everything to everyone, but we can have a
| good shot at getting close in most cases.

Sure, packages are expected to work after installation. Does providing a
cron entry count as part of working? Not for some packages. Does
installing a bash completion entry count as part of working? Not for
most packages. No-one (sane, anyway) is opposed to decent default
config files going into /etc automatically where such a thing is
possible. The question is how to handle the high cost extras.

| > For packages in the first group, a USE flag is 
| > silly. 
| 
| Why, there may be cases where what you think should require cron,
| doesn't for that particular user and besides which again we are
| talking about a tiny minority from what I can see.

If that's the case, either your package isn't in the first category or
the user is doing something especially weird. Users doing especially
weird things are on their own.

| > For packages in the second group, not using a USE flag is silly. 
| 
| I take it you are agreeing we should have a USE flag for these
| ebuilds?

For packages where /etc entries are "wanted by some, not wanted by
some", yes.

| > For the in-between cases, that's one of those areas where the ebuild
| > maintainer has to make an educated decision.
| 
| and here is the nature of the problem imho. Currently everyone is
| making these educated decisions and it means there is no coherency at
| all.

Nooooo! The educated decisions include "how everyone else is handling
the issue".

| Why not say something like "Where possible, all ebuilds should
| work after being emerged. Example configuration files should be
| installed in /usr/share/doc, and additional administration scripts /
| configuration should be done via the global use flag FOO" where foo
| is cron or logrotate as an example. I understand that it isn't
| perfect for EVERYTHING, but then there is no one solution for
| everything, and having something like that would certainly be a lot
| clearer to developers and users alike as to how to go about doing
| things instead of having to read ewarn / einfo as they fly by on how
| to specifically do things for that specific ebuild.

Hah, I tried that with devmanual. The problem is, the worst offenders
for doing perverse things in ebuilds are the same ones who won't accept
any documentation that isn't official and marked mandatory and who will
block any documentation of existing practice from becoming policy
because it isn't policy.

-- 
Ciaran McCreesh : Gentoo Developer (King of all Londinium)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm