I'm wondering out loud if these versions should follow the openbsd shlib major minor numbers. That is where we are careful about semantic versioning for api change/add/remove
On Monday, August 10, 2015, Brent Cook <[email protected]> wrote: > On Mon, Aug 10, 2015 at 5:10 AM, Mark Kettenis <[email protected] > <javascript:;>> wrote: > > Jan Engelhardt schreef op 2015-08-10 10:29: > > > >> On Monday 2015-08-10 02:38, Brent Cook wrote: > >>>> > >>>> On Aug 9, 2015, at 10:07 AM, Jan Engelhardt <[email protected] > <javascript:;>> wrote: > >>>> > >>>>> We have released LibreSSL 2.2.2, which will be arriving in the > >>>>> LibreSSL directory of your local OpenBSD mirror soon. > >>>> > >>>> > >>>> The .pc files in libressl-2.2.2 upset the package mechanisms at hand, > in > >>>> particular rpm, where ':' is used to denote the (ancient concept of) > >>>> epochs. > >>>> > >>>> [ 99s] Invalid version (double separator ':'): 35:0:0: > >>>> mingw32(pkg:libcrypto) = 35:0:0 > >>>> [ 99s] mingw32(pkg:libssl) = 35:0:0 > >>>> [ 99s] mingw32(pkg:libtls) = 6:0:0 > >>>> [ 99s] mingw32(pkg:openssl) = 2.2.2 > >>>> > >>>> The version: field in .pc files is (still) supposed to be the > >>>> package version number, not the ABI number, and this was not a problem > >>>> in libressl <= 2.2.1. > >>> > >>> > >>> Thanks for the note, Jan. > >>> > >>> Right or wrong, I'm fairly certain the format has not changed any time > >>> recently, e.g. here is the libtls .pc file from 2.2.1: > >> > >> > >> So it turns out rpm does not consider it an error, just a warning (but > it > >> is the first time the warning showed up on the last screenful, the one > >> paid most attention to). > >> > >>> I'm not so sure that this should be the package version number though. > >>> Can you > >>> point to some further documentation here? > >> > >> > >> pkg-config(1): "Version: > >> This should be the most-specific-possible package version > >> string." > >> > >> * x:0:0 is not specific enough, as it would not change when the ABI-API > >> stays unmodified between two releases. > >> > >> * the observation that all other .pc files I happen to have installed > >> on my machine right now (some 194) all match \d+(\.\d+)* > > Thanks. That matches my observation too. > > > > > Right. Brent, looks like you used the libtool version specification > here, > > which is (primarily) about encoding the ABI. But for pkg-config it's > > the API that's important. Hence the tradition to simply use the package > > version number here, since that will change (by definition) when the API > > changes, but will also change when there are just some bug fixes (which > > people might want to check for). Configure scripts will often contain > > checks > > for the package version number to be larger or equal (using pkg-config > > --atleast-version) to some version that is known to have all features > > required for building the software. > > > > So I think all the .pc files in LibreSSL should simply use the LibreSSL > > version number (2.2.2) like the openssl.pc does. This does mean that > > checking > > for individual libraries in LibreSSL version 2.2.2 and older will > probably > > busted, but such is life. Not sure how the colon-separated version > strings > > interact with --atleast-version. Might be worth checking that out. > > The main exception I found was that ffmpeg encoded ABI rather than API > in its .pc files too, but your explanations make sense to me. > > I'm happy that people are noticing issues like this now, since it > means the files are getting some use :) I'll make the change for the > next release. > > > Cheers, > > > > Mark > > > > P.S. OpenBSD still ships with .pc files that have 1.0.0 as the version > > number. We might want to change that at some point, but this should be > > coordinated with the ports people. > > > > > >
