1 |
Thomas Pani wrote: |
2 |
> My concern is technical: Filenames are for identifying files uniquely. |
3 |
> An ebuild is uniquely identified by <cat>/<pn>-<pv>, so that's what it's |
4 |
> filename should be. Adding anything else to the filename will only |
5 |
> clutter the tree and lead to additional inconsitencies. Yes, you can |
6 |
> check for these using QA tools. But if it's not in the filename you |
7 |
> don't have to check. |
8 |
> If you say that package managers need the EAPI info so early that they |
9 |
> can't even read the first non-comment line of an ebuild that's fine. Go |
10 |
> and place it in the filename. But nobody had a *technical* argument why |
11 |
> that's the only possible solution so far. All I got was "you don't |
12 |
> understand all that fancy PM stuff". |
13 |
|
14 |
Good point. First of all, and this is an architecture/design issue, the only |
15 |
valid reason to put the EAPI in the filename is that is *belongs* there in |
16 |
principal. File extensions are for file types, not for info that really |
17 |
should be in the file. If the motivation for placing the info in the filename |
18 |
(and worse, the *extension*) is that of performance, you should think twice |
19 |
about putting it there. If this is to address a technical problem, it should |
20 |
be solved in a technical way. The format of a filename should be determined |
21 |
by policy, not technical implementation or convenience. |
22 |
|
23 |
Technical reasons to avoid the filename are: |
24 |
|
25 |
1) Increase of [needless] complexity in filenames/extensions (and only one |
26 |
example of the impact is that searching for ebuild files becomes less |
27 |
straightforward). |
28 |
2) Having the same info in more than one place is bad (requiring extra repoman |
29 |
checks and the potential for ambiguity). I don't care how many people |
30 |
say a) that this is not an issue or b) that it's "not a duplication", |
31 |
in every data system I've worked on, it has been a very bad idea to have |
32 |
more than one version of the same info that can get out of sync with each |
33 |
other. Even if you take great care, I'd still always want to check both |
34 |
and not trust either version of the info blindly. Caching or hashing is |
35 |
different (i.e. where the caching mechanism is robust), since the |
36 |
system itself keeps the cache up to date, and one version of the info |
37 |
is stricty derived from the other rather than both being the source. |
38 |
3) It uses the extension in a way that goes against common use in computers. |
39 |
|
40 |
Other reasons: |
41 |
|
42 |
1) Littering the filename with this kind of stuff is potentially confusing do |
43 |
both devs and users - I know it's been stated that users don't care, but |
44 |
I don't think that's a good assumption. |
45 |
2) It does not appear to be an elegant filename policy (and this can be |
46 |
considered technical as well), since elegance is something designed int |
47 |
good systems. |
48 |
3) Assuming going this route is a mistake, it could be hard to reverse. |
49 |
|
50 |
I just don't want to see something like this happen as a quick fix without |
51 |
exploring all of the implications and how it effects what I consider a very |
52 |
good system (portage/ebuilds) currently. Also, it seems to me that there are |
53 |
lots of other alternatives that have been discussed here (and some dismissed |
54 |
rather quickly). Portage and its policy are very core to Gentoo, and care |
55 |
should be taken on this. |
56 |
|
57 |
-Joe |
58 |
|
59 |
P.S. I just joined Gentoo this year, and it is disheartening to see the |
60 |
nastiness that some people are resorting to on this list. I've never seen so |
61 |
much anger and biting remarks in a project, and I can imagine it keeps some |
62 |
from responding, which is ashame, since issues like this benefit from many |
63 |
diverse viewpoints. |
64 |
-- |
65 |
gentoo-dev@g.o mailing list |