1 |
Joe Peterson schrieb: |
2 |
> Ciaran McCreesh wrote: |
3 |
>> On Mon, 09 Jun 2008 19:49:08 -0600 |
4 |
>> Joe Peterson <lavajoe@g.o> wrote: |
5 |
>>> Well, in general, if you rely on extensions changing every time a |
6 |
>>> program cannot deal with a new feature of a file format, it would be |
7 |
>>> quite crazy. For example, if C programs had to start using ".c-2", |
8 |
>>> ".c-3", etc., it would get ugly fast. |
9 |
>> Which is why programs that use any major C feature introduced since |
10 |
>> 1980 use the extension '.cc' or '.cpp'. |
11 |
> |
12 |
> So why would not a one-time new extension (e.g. ".eb") do the trick, |
13 |
> just like ".cc" works for C programs? Unless you are talking about |
14 |
> needing to specify the EAPI in the file if the more advanced features |
15 |
> are to be used, but I see nothing wrong with that requirement - it's not |
16 |
> much different than specifying a slot, keywords, whatever. |
17 |
Because that is about the same "damage" (file ext. changes, people might |
18 |
get confused etc.) with less capabilities. |
19 |
|
20 |
>>> Also, it is easy to build EAPI checking into portage now, and when |
21 |
>>> the requisite time passes, you only need to deal with situations |
22 |
>>> where *very* old portage versions are still in use. Since portage is |
23 |
>>> typically the first thing the system upgrades after a sync, I don't |
24 |
>>> see a big issue. Or, if that is not acceptable, see my comment at |
25 |
>>> the end about a one-time change to a new extension like ".eb". |
26 |
>> You completely miss the point of the GLEP. We need new extensions |
27 |
>> precisely because current package managers can't handle future EAPIs |
28 |
>> cleanly, and we need to carry on using new extensions because otherwise |
29 |
>> we restrict what future EAPIs can do. |
30 |
> |
31 |
> No, I get that. But once you develop the concept of an EAPI, the very |
32 |
> next package manager version can be aware of it and check the EAPI of an |
33 |
> ebuild. If the ebuild specifies none, then it is old-style. If it |
34 |
> specifies one that is unknown or newer than what that package manager |
35 |
> version knows it can handle, it can handle that case (ignore it or |
36 |
> whatever). I don't see why you need to keep bumping the |
37 |
> filename/extension every time it changes from that point forward. |
38 |
Because you can change the EAPI in a way that that may not work anymore. |
39 |
Specifying the EAPI outside the actual ebuild is more flexible. |
40 |
It doesn't have to be the file extension, but that is the obvious solution. |
41 |
|
42 |
>>> But what users *really* don't care about is EAPIs, and this GLEP would |
43 |
>>> expose that technical detail to them in a very blatent way. |
44 |
>> Anyone who cares about ebuilds at a file level has to care about EAPIs. |
45 |
> |
46 |
> Not really. A typical user does not need to know about EAPIs at all, |
47 |
> but he might want to peruse the portage tree to look for ebuilds. He |
48 |
> might also want to grep for KEYWORDS or whatever. The user can delve |
49 |
> into it as much as needed or desired, but if there are these mysterious |
50 |
> EAPI numbers tacked onto the extensions, then it's an added complication |
51 |
> that is not important to all users. |
52 |
No, not really. If you have .txt, .txt-2, .text or .footext in a dir, |
53 |
you would still realize, that those should be text files. |
54 |
Of course, a future EAPI could be named .whatevercomestoyourmind, but |
55 |
first, you can expect people to be smart enough to not do that and |
56 |
second, you can still identify the packages, because they are still |
57 |
named foo-version.whatevercomestoyourmind. |
58 |
|
59 |
Bernd |
60 |
|
61 |
|
62 |
-- |
63 |
gentoo-dev@l.g.o mailing list |