| 1 |
Richard Freeman wrote: |
| 2 |
> I still don't see why we need to be encoding metadata in filenames. |
| 3 |
|
| 4 |
Correct. GLEP 55 tries to solve a technical implementation issue by |
| 5 |
exposing meta data in the filename. Extremely bad form/design, IMHO. |
| 6 |
|
| 7 |
> PERL doesn't care what a file extension is, python doesn't care, bzip2 |
| 8 |
> doesn't care, tar doesn't care, gzip doesn't care, and even ld-linux.so |
| 9 |
> doesn't care. I'm sure that in at least some of these cases they end up |
| 10 |
> parsing parts of the file twice - once to figure out what it is, and the |
| 11 |
> second time to actually handle it. I'm actually hard pressed to think |
| 12 |
> of any unix-based software that uses the filename to store a mandatory |
| 13 |
> file format versioning specifier of some kind. |
| 14 |
|
| 15 |
All good points. I cannot believe there exists no other way to solve |
| 16 |
this technical issue other than resorting to such a non-Unix-like idea. |
| 17 |
Obviously all of the software packages cited above endeavor to avoid |
| 18 |
such nastiness. |
| 19 |
|
| 20 |
I do not understand why anyone is willing to accept putting version info |
| 21 |
in the filename/extension. It is inelegant and, frankly, very ugly. I |
| 22 |
have written more in the past on why I think it is a terrible idea, so I |
| 23 |
won't repeat it here. |
| 24 |
|
| 25 |
Suffice to say, if something like GLEP 55 is implemented, I will lose a |
| 26 |
lot of faith in Gentoo's design, so much so that I will likely join the |
| 27 |
ranks of those who abandon it, not only as a dev, but also as a user. |
| 28 |
|
| 29 |
> This seems to me to be a solved problem. You put a header in a file |
| 30 |
> that tells you how to read the file. Headers are split into fields and |
| 31 |
> if a program doesn't know what to do with a field it ignores it (or if |
| 32 |
> the header so instructs it doesn't even try to parse the file). This |
| 33 |
> should be easy to do and keep the file bash-compatible. Just stick a |
| 34 |
> comment line close to the top of the file and put whatever you want on |
| 35 |
> it. You could also stick something in metadata.xml (although this makes |
| 36 |
> working with ebuilds outside of a repository more difficult). You run |
| 37 |
> the file through an algorithm to find out what the EAPI is, and then |
| 38 |
> source it if appropriate. |
| 39 |
> |
| 40 |
> Sure, if you make some major change analogous to switching from the .rpm |
| 41 |
> to the .deb package format then maybe an extension change would make |
| 42 |
> sense. But, why expose the inner workings of the package file format to |
| 43 |
> the filesystem? |
| 44 |
|
| 45 |
+100 |
| 46 |
|
| 47 |
-Joe |
Archives