Gordon Messmer wrote:
> I'm not sure if that means that you are opposed to the proposal, or to
> the idea of truncating the version numbers, or something else entirely.
> :)
I see the value of the proposal, but I am worried that it may run into
issues with upstream packages using very weird library version numbers, so I
am not yet convinced that it is really a good idea.
The more operations you do to the version numbers (e.g., truncating), the
higher the risk that something gets messed up. I can see why you would want
to avoid unnecessarily strict requirements, but some libraries add APIs even
in last-digit version numbers, so you may end up missing a needed versioned
dependency.
In the end, I am not sure whether this is really safe to automate. Though
the current practice of manually adding such versioned requirements is
clearly not working, as we packagers often have no idea what version we
should require, also depending on what version happened to be used at build
time. (I do not blame the packagers for that. I am one myself and really do
not want to get into adding such versioned dependencies manually.)
On the other hand, I do not know how many of the weird versioning examples I
have shown below actually come up in the wild. I am pretty sure I have seen
examples of the:
>> libfoo.so → libfoo.so.1 → libfoo.so.4.5.6
>> libfoo.so → libfoo.so.4 → libfoo.so.1.2.3
type (and cursed at them), and I definitely have seen non-numeric versioning
(such as Fedora using a downstream soversion with "rh" in it, e.g.,
"libfoo.so.7rh"). But I have not yet run into projects using SCM revisions
(monotonic or not) in the version numbers.
>> The full version (or even the soversion, for that matter) is also not
>> guaranteed to be monotonic in any way. E.g., you could have:
>> libfoo.so → libfoo.so.1 → libfoo.so.1.deadbeef
>> or even just:
>> libfoo.so → libfoo.so.1 → libfoo.so.deadbeef
>> where "deadbeef" is a non-monotonic SCM hash (e.g., a git hash).
>
> Right... as above, those would remain unversioned.
Well, there is a corner case in that a git hash is a hex number, which can
happen to be all digits.
Kevin Kofler
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
