Gentoo Archives: gentoo-dev

From: Ciaran McCreesh <ciaranm@g.o>
To: "Benjamin Smee (strerror)" <strerror@g.o>
Cc: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Default Ebuild behaviour
Date: Tue, 31 Jan 2006 17:39:07
Message-Id: 20060131172442.5c878a3d@snowdrop.home
In Reply to: Re: [gentoo-dev] Default Ebuild behaviour by "Benjamin Smee (strerror)"
1 On Tue, 31 Jan 2006 17:06:35 +0000 "Benjamin Smee (strerror)"
2 <strerror@g.o> wrote:
3 | On Tuesday 31 January 2006 15:47, Ciaran McCreesh wrote:
4 | > | What is the "cost" you are referring to specifically? I think I
5 | > | know but I'd like a specific definition.
6 | >
7 | > 1. Management. For example, handling etc-update.
8 |
9 | That is surely a "cost" people have for upgrading an application and
10 | have implicitly accepted by doing so.
12 Not really. There's a basic cost of installing or upgrading an
13 application, but there's also additional cost that comes from optional
14 extras.
16 | > 3. Performance. Entries in /etc can have a serious performance
17 | > impact. The easy example is bash completion, which can be
18 | > reaaallllly slow if you have a few hundred entries.
19 |
20 | I find this hard to swallow. You could say that about any directory
21 | that is over a certain size, say typically /dev. Thats even on the
22 | assumption that most people use bash completion constantly or that on
23 | modern hardware it is a noticeable problem, which in my experience is
24 | not the case.
26 Noooooo! Not the cost from using a sucky filesystem. The cost from your
27 application of choice having to parse all those files. Bash is a good
28 example -- it's not particularly fast (read: very slow) at parsing
29 scripts, and if you have a zillion bash completion scripts installed
30 then something as simple as starting a terminal can take a very long
31 time. It's precisely this that lead to bash-completion-config.
33 | Then change the default configuration so that it only updates for the
34 | directories that you want. The expectation that a package works after
35 | an emerge is in 99% of cases perfectly reasonable, and if its not
36 | perfect for one persons particular environment then the onus is on
37 | them to fix it. We can't be everything to everyone, but we can have a
38 | good shot at getting close in most cases.
40 Sure, packages are expected to work after installation. Does providing a
41 cron entry count as part of working? Not for some packages. Does
42 installing a bash completion entry count as part of working? Not for
43 most packages. No-one (sane, anyway) is opposed to decent default
44 config files going into /etc automatically where such a thing is
45 possible. The question is how to handle the high cost extras.
47 | > For packages in the first group, a USE flag is
48 | > silly.
49 |
50 | Why, there may be cases where what you think should require cron,
51 | doesn't for that particular user and besides which again we are
52 | talking about a tiny minority from what I can see.
54 If that's the case, either your package isn't in the first category or
55 the user is doing something especially weird. Users doing especially
56 weird things are on their own.
58 | > For packages in the second group, not using a USE flag is silly.
59 |
60 | I take it you are agreeing we should have a USE flag for these
61 | ebuilds?
63 For packages where /etc entries are "wanted by some, not wanted by
64 some", yes.
66 | > For the in-between cases, that's one of those areas where the ebuild
67 | > maintainer has to make an educated decision.
68 |
69 | and here is the nature of the problem imho. Currently everyone is
70 | making these educated decisions and it means there is no coherency at
71 | all.
73 Nooooo! The educated decisions include "how everyone else is handling
74 the issue".
76 | Why not say something like "Where possible, all ebuilds should
77 | work after being emerged. Example configuration files should be
78 | installed in /usr/share/doc, and additional administration scripts /
79 | configuration should be done via the global use flag FOO" where foo
80 | is cron or logrotate as an example. I understand that it isn't
81 | perfect for EVERYTHING, but then there is no one solution for
82 | everything, and having something like that would certainly be a lot
83 | clearer to developers and users alike as to how to go about doing
84 | things instead of having to read ewarn / einfo as they fly by on how
85 | to specifically do things for that specific ebuild.
87 Hah, I tried that with devmanual. The problem is, the worst offenders
88 for doing perverse things in ebuilds are the same ones who won't accept
89 any documentation that isn't official and marked mandatory and who will
90 block any documentation of existing practice from becoming policy
91 because it isn't policy.
93 --
94 Ciaran McCreesh : Gentoo Developer (King of all Londinium)
95 Mail : ciaranm at
96 Web :


File name MIME type
signature.asc application/pgp-signature


Subject Author
Re: [gentoo-dev] Default Ebuild behaviour Donnie Berkholz <spyderous@g.o>
Re: [gentoo-dev] Default Ebuild behaviour "Benjamin Smee (strerror)" <strerror@g.o>