1 |
-----BEGIN PGP SIGNED MESSAGE----- |
2 |
Hash: SHA1 |
3 |
|
4 |
heya, |
5 |
|
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. |
11 |
|
12 |
That is surely a "cost" people have for upgrading an application and have |
13 |
implicitly accepted by doing so. |
14 |
|
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... |
18 |
|
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. |
25 |
|
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. |
29 |
|
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. |
35 |
|
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. |
40 |
|
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. |
47 |
|
48 |
> Not really. For some packages, cron files must always be installed for |
49 |
> proper operation. |
50 |
|
51 |
Granted, but that is probably a VERY small number, certainly not a |
52 |
majority and falls under exceptions. |
53 |
|
54 |
> For some packages, cron files are strictly optional |
55 |
> extras for features that many users will not want. |
56 |
|
57 |
Hence USE. |
58 |
|
59 |
> For many it's |
60 |
> somewhere in between. |
61 |
|
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". |
69 |
|
70 |
> For packages in the first group, a USE flag is |
71 |
> silly. |
72 |
|
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. |
76 |
|
77 |
> For packages in the second group, not using a USE flag is silly. |
78 |
|
79 |
I take it you are agreeing we should have a USE flag for these ebuilds? |
80 |
|
81 |
> For the in-between cases, that's one of those areas where the ebuild |
82 |
> maintainer has to make an educated decision. |
83 |
|
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. |
96 |
|
97 |
- -- |
98 |
Benjamin Smee (strerror) |
99 |
crypto/forensics/netmail/netmon |
100 |
-----BEGIN PGP SIGNATURE----- |
101 |
Version: GnuPG v1.9.20 (GNU/Linux) |
102 |
|
103 |
iD8DBQFD35keAEpm7USL54wRAqcRAJ9PhaIYHPQJ9QD2DfgPBkSBi+Af9ACffAUl |
104 |
CLB4LC/8BRaH0qL1jwsUuQA= |
105 |
=QoCM |
106 |
-----END PGP SIGNATURE----- |
107 |
-- |
108 |
gentoo-dev@g.o mailing list |