| 1 |
Douglas Anderson wrote: |
| 2 |
> No one wants to be working with ebuild-29 or something like that in a |
| 3 |
> few years and trying to figure out which feature came in which EAPI. |
| 4 |
> Instead of bumping EAPI for each little change, save them up and bump |
| 5 |
> no more than once a year or less, each bump bringing in some major new |
| 6 |
> feature. |
| 7 |
|
| 8 |
I got the impression that if anything there is a desire to allow EAPIs |
| 9 |
to change more offen, and not less. And these changes could become more |
| 10 |
dramatic. I'm not sure this is actually a bad thing (within reason - we |
| 11 |
do need to have clear specifications for anything that hits production |
| 12 |
so that we don't have a package manager mess). |
| 13 |
|
| 14 |
Also - keep in mind that EAPIs do not need to be numbers and are not |
| 15 |
ordered. You could have ebuild-i_am_a_furry_monkey or |
| 16 |
ebuild-<bunch-of-stuff-in-unicode-that-maybe-your-terminal-displays>. |
| 17 |
Sure - hopefully the names will be more sensible and somewhat uniform, |
| 18 |
but we're not necessarily just talking about adding a number to the |
| 19 |
extension. |
| 20 |
|
| 21 |
I still don't see why we need to be encoding metadata in filenames. |
| 22 |
PERL doesn't care what a file extension is, python doesn't care, bzip2 |
| 23 |
doesn't care, tar doesn't care, gzip doesn't care, and even ld-linux.so |
| 24 |
doesn't care. I'm sure that in at least some of these cases they end up |
| 25 |
parsing parts of the file twice - once to figure out what it is, and the |
| 26 |
second time to actually handle it. I'm actually hard pressed to think |
| 27 |
of any unix-based software that uses the filename to store a mandatory |
| 28 |
file format versioning specifier of some kind. |
| 29 |
|
| 30 |
This seems to me to be a solved problem. You put a header in a file |
| 31 |
that tells you how to read the file. Headers are split into fields and |
| 32 |
if a program doesn't know what to do with a field it ignores it (or if |
| 33 |
the header so instructs it doesn't even try to parse the file). This |
| 34 |
should be easy to do and keep the file bash-compatible. Just stick a |
| 35 |
comment line close to the top of the file and put whatever you want on |
| 36 |
it. You could also stick something in metadata.xml (although this makes |
| 37 |
working with ebuilds outside of a repository more difficult). You run |
| 38 |
the file through an algorithm to find out what the EAPI is, and then |
| 39 |
source it if appropriate. |
| 40 |
|
| 41 |
Sure, if you make some major change analogous to switching from the .rpm |
| 42 |
to the .deb package format then maybe an extension change would make |
| 43 |
sense. But, why expose the inner workings of the package file format to |
| 44 |
the filesystem? |
Archives