On Sun, Sep 03 2023, Jonathan Schleifer <[email protected]> wrote:
> Am 03.09.23 um 12:55 schrieb Jeremie Courreges-Anglas:
>
>> On Sun, Sep 03 2023, Jonathan Schleifer <[email protected]> wrote:
>>> Am 31.08.23 um 09:56 schrieb Jonathan Schleifer:
>>>
>>>> Am 31.08.23 um 08:26 schrieb Stuart Henderson:
>>>>>>> SHARED_LIBS += objfw 1.0
>>>>>>> SHARED_LIBS += objfwrt 1.0
>>>>>>> SHARED_LIBS += objfwtls 1.0
>>>>>> I can't remember how strict we are with these version starting numbers
>>>>>> but iirc we start with 0.1 (?) I don't really mind if this isn't
>>>>>> changed.
>>>>>> The bumpings are the more important ones anyway.
>>>>> 0.0.
>>>>>
>>>>> The key thing is to make sure that changing the versions in SHARED_LIBS
>>>>> changes the versions of the produced file, i.e. make sure that ports is
>>>>> in control.
>>>> Ok, now I have questions :).
>>>>
>>>> I was under the impression that the the SHARED_LIBS should match the
>>>> .so name? This would be the case with 1.0, as upstream used 0.0 during
>>>> development when there was no stable ABI/API (and users could have
>>>> installed such a pre-1.0 release manually on OpenBSD). I could find
>>>> https://man.openbsd.org/library-specs.7 which seems to indicate it
>>>> must match the .so name, as well as lining out rules on when and how
>>>> to update the version, which match upstream in this case (I can vouch
>>>> for this, as I am the upstream).
>>>>
>>>> Given that, wouldn't it be better to have it 1.0 instead of always one
>>>> major version less than upstream?*
>>>>
>>>> * Very, very early, there was a major version of as high as 8. But
>>>> this was a decade or so ago and I think nobody ever used it. And on
>>>> a version that was very much declared "this WILL break, don't use this
>>>> for anything"
>>> I'm happy to change it to 0.0, of course, but would really like to fully
>>> understand the implications of this. Should every port, when imported to
>>> OpenBSD, change the soname to 0.0?
>> The library version should be 0.0 for a new port and the soname should
>> match the library name.
>
> Ah, OK, so then I was confused by the documentation, which I interpreted
> as it needs to match. Then I see absolutely no reason why it shouldn't
> be set to 0.0 indeed.
>
>> That's how we handle it in ports, with all due
>> respect that's not something that you, as an upstream, should feel
>> concerned about IMO.
>
> Sorry, I didn't mean to question the way you do things in OpenBSD ports,
> I was merely trying to understand if that has any implications for
> soname.
>
>> The version used in ports may stay at 0.0 or move to 0.1 or 1.0, 2.0
>> etc, it depends on how you (upstream) preserve or change API and ABI in
>> the future, but it may also depend on changes in the OpenBSD base system
>> and ports tree. That's why the port for objfw should have complete
>> control about the version used.
>
> All good then! Should I send another tarball with it set to 0.0, or is
> this small enough for whoever imports it to just do it?
This would be small enough if the package still built. Moving
SHARED_LIBS to 0.0 I get:
Error: /usr/obj/pobj/objfw-1.0/fake-amd64/usr/local/lib/libobjfw.so.0.0 does
not exist
Error: /usr/obj/pobj/objfw-1.0/fake-amd64/usr/local/lib/libobjfwrt.so.0.0 does
not exist
Error: /usr/obj/pobj/objfw-1.0/fake-amd64/usr/local/lib/libobjfwtls.so.0.0 does
not exist
at make package time. This is what Stuart meant when he said that the
port should be in control: SHARED_LIBS should decide the version used to
build and install the shared libraries. For automake or cmake ports this
is usually handled transparently by the ports infrastructure, which sets
various values in the build environment. Here you don't seem to use
automake so you're probably going to need patches + ${SUBST_CMD} to inject
LIBobjfw_VERSION etc at the right spot.
Regarding the port, I see two nits:
- Portable -> portable in COMMENT
- maybe include your full name in MAINTAINER
- .SILENT doesn't help understanding what is going on
and I wonder about two things:
- COMPILER + COMPILER_LANGS: is COMPILER_LANGS actually useful here?
- is this framework already used by other applications in the wild?
Could it be used as a building block for other ports? Do we have to
care about some existing ports automatically picking it up?
That's a lot of questions, sorry :)
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
