Gentoo Archives: gentoo-dev

From: "Benjamin Smee (strerror)" <strerror@g.o>
To: gentoo-dev@l.g.o
Cc: Ciaran McCreesh <ciaranm@g.o>
Subject: Re: [gentoo-dev] Default Ebuild behaviour
Date: Tue, 31 Jan 2006 17:12:28
In Reply to: Re: [gentoo-dev] Default Ebuild behaviour by Ciaran McCreesh
2 Hash: SHA1
4 heya,
6 On Tuesday 31 January 2006 15:47, Ciaran McCreesh wrote:
7 > | What is the "cost" you are referring to specifically? I think I know
8 > | but I'd like a specific definition.
9 >
10 > 1. Management. For example, handling etc-update.
12 That is surely a "cost" people have for upgrading an application and have
13 implicitly accepted by doing so.
15 > 2. Administration. Everything in /etc must be checked and covered by
16 > backup policies and the like. Unless you're a home user, in which case
17 > you probably just hope for the best...
19 Sounds similar to point 1, in the case of backups, I'd suggest that most
20 policies would cover the entire box, or at the very least the entire /etc
21 and all its subdirs. In my experience as an admin we always just back up
22 the entire machine, I don't see how adding things in here makes a
23 significant difference for most users, and where it does, eg embedded,
24 they can chose not to install things, via for example, USE.
26 > 3. Performance. Entries in /etc can have a serious performance impact.
27 > The easy example is bash completion, which can be reaaallllly slow if
28 > you have a few hundred entries.
30 I find this hard to swallow. You could say that about any directory that
31 is over a certain size, say typically /dev. Thats even on the assumption
32 that most people use bash completion constantly or that on modern
33 hardware it is a noticeable problem, which in my experience is not the
34 case.
36 > Less obvious examples are cron entries
37 > for things like updatedb -- if you have a few dozen chroots and svn
38 > checkouts of large projects, updatedb can take a very long time and eat
39 > a lot of battery power.
41 Then change the default configuration so that it only updates for the
42 directories that you want. The expectation that a package works after an
43 emerge is in 99% of cases perfectly reasonable, and if its not perfect
44 for one persons particular environment then the onus is on them to fix
45 it. We can't be everything to everyone, but we can have a good shot at
46 getting close in most cases.
48 > Not really. For some packages, cron files must always be installed for
49 > proper operation.
51 Granted, but that is probably a VERY small number, certainly not a
52 majority and falls under exceptions.
54 > For some packages, cron files are strictly optional
55 > extras for features that many users will not want.
57 Hence USE.
59 > For many it's
60 > somewhere in between.
62 Here we disagree. Give me some numbers, because from my research i'd
63 suggest that while there are some packages in your first category, almost
64 everything else would fall into the second. Again, even if there are some
65 that don't its not going to be many, we are after getting something that
66 will work for as many as possible, some consistancy rather then saying
67 "look there is no one solutation that will be perfect so lets give up
68 now".
70 > For packages in the first group, a USE flag is
71 > silly.
73 Why, there may be cases where what you think should require cron, doesn't
74 for that particular user and besides which again we are talking about a
75 tiny minority from what I can see.
77 > For packages in the second group, not using a USE flag is silly.
79 I take it you are agreeing we should have a USE flag for these ebuilds?
81 > For the in-between cases, that's one of those areas where the ebuild
82 > maintainer has to make an educated decision.
84 and here is the nature of the problem imho. Currently everyone is making
85 these educated decisions and it means there is no coherency at all. Why
86 not say something like "Where possible, all ebuilds should work after
87 being emerged. Example configuration files should be installed
88 in /usr/share/doc, and additional administration scripts / configuration
89 should be done via the global use flag FOO" where foo is cron or
90 logrotate as an example. I understand that it isn't perfect for
91 EVERYTHING, but then there is no one solution for everything, and having
92 something like that would certainly be a lot clearer to developers and
93 users alike as to how to go about doing things instead of having to read
94 ewarn / einfo as they fly by on how to specifically do things for that
95 specific ebuild.
97 - --
98 Benjamin Smee (strerror)
99 crypto/forensics/netmail/netmon
101 Version: GnuPG v1.9.20 (GNU/Linux)
104 CLB4LC/8BRaH0qL1jwsUuQA=
105 =QoCM
106 -----END PGP SIGNATURE-----
107 --
108 gentoo-dev@g.o mailing list


Subject Author
Re: [gentoo-dev] Default Ebuild behaviour Ciaran McCreesh <ciaranm@g.o>