Am 03.09.23 um 19:55 schrieb Stuart Henderson:
yep, exactly. reasons:
- we find that some upstream projects don't understand shared library
versioning, and either increment the version number when not needed, or
don't increment when it is needed.
Upstream handling reads exactly like OpenBSD handling, so this case is
probably fine. (minor increased for new symbols, major increased on ABI
break)
as this information is used to trigger
updates of packages depending on a library after that library has
changed incompatibly, it needs to work otherwise people get mismatching
library+other packages.
- in the past (rarely) we've had to bump library versions in ports after
a major incompatible change in system headers/libraries
I think we're unlikely to use this second reason again, we have a
different mechanism to force updates of all ports which is more
convenient now, but even ignoring that the first reason is enough.
and considering that when a port is brought into OpenBSD the upstream
library version is often >0.0, making sure that ports start with 0.0
means that we can check that ports is indeed in control of the version
number.
I guess since the second case is unlikely, in practice, OpenBSD's
version will always be one major version less than upstream. But hey, if
that is required to show "we're using OpenBSD library versions here and
not upstream versions", so be it. My concern is just someone having it
installed without ports on OpenBSD - and then there is a lot of fun with
library versions being exactly one major version apart. Seems like
asking for trouble on systems where you have both, ports and non-ports
versions.
please don't do this, patches straight from github are fragile and
easily change e.g. when the shortened commit hash is no longer unique
they add an extra hex digit.
if you must fetch a patch from elsewhere please use a static file rather
than an on-the-fly generated one, but preferably include the patches in
the port (copy the original files with an .orig.port suffix in the work
directory and apply patches, then run "make update-patches" to generate
files with the correct format and filename conventions)
I realized that patch is not needed at all, as both versions are 1.0 in
this release. Only in the future, when they diverge, such a patch would
be required. However, any future release will already include the patch,
so, including it is not necessary and just setting the variables like it
already were will just magically make it work with the next update.
--
Jonathan
