| 1 |
Ryan Hill wrote: |
| 2 |
>> Richard Freeman wrote: |
| 3 |
>>> I'm |
| 4 |
>>> actually hard pressed to think of any unix-based software that uses |
| 5 |
>>> the filename to store a mandatory file format versioning specifier |
| 6 |
>>> of some kind. |
| 7 |
> |
| 8 |
> $ ls /usr/lib |
| 9 |
|
| 10 |
|
| 11 |
I was referring to a file FORMAT versioning scheme - not a file CONTENT |
| 12 |
versioning scheme. The formats of all the files in /usr/lib are |
| 13 |
generally identical. Where they vary it has nothing to do with their |
| 14 |
filenames. The reason for the version in the filenames is that the |
| 15 |
content is versioned. |
| 16 |
|
| 17 |
The dynamic linker doesn't need to consult the filename to figure out |
| 18 |
how to parse a shared object. It only consults the filename to figure |
| 19 |
out which shared object is needed. That is actually analogous to |
| 20 |
putting the package name/version in the ebuild filename. |
| 21 |
|
| 22 |
In any case, I'm not trying to say that these issues absolutely prevent |
| 23 |
the adoption of GLEP 55. It just leaves a sour taste in my mouth, and |
| 24 |
keeps nagging at me that there must be a better way. |
| 25 |
|
| 26 |
I'd rather see the number of filename variations be kept to a minimum. |
| 27 |
Sure, if we were talking about a one-time change from ebuild to ebuild2 |
| 28 |
and in five years a change to ebuild3 then that would be one thing. It |
| 29 |
seems like we could be up to ebuild-kde4-3.2 in six months. |
| 30 |
|
| 31 |
And I don't mean to suggest that I don't think that efforts would be |
| 32 |
made to keep things sensible. It just seems like once we start down |
| 33 |
that road it will be hard to turn around if we don't like where we end up. |
Archives