On Tue, Jun 07, 2022 at 10:26:08AM +0100, Stuart Henderson wrote: > The version checks are done using the pkgname, the path has nothing to do > with it other than to lookup the pkgname (and pkgspec if present). > > > By overriding the existing pkgspec coming from security/OpenSSL/X.Y, you are > taking responsibility for it, so you need to replicate+modify the existing > spec, there's no means to allow checking against multiple different specs. > > > -- > Sent from a phone, apologies for poor formatting. > > On 7 June 2022 05:19:11 Klemens Nanni <[email protected]> wrote: > > > On Tue, Jun 07, 2022 at 04:10:40AM +0000, Klemens Nanni wrote: > > > Is our code tripping over a PKGSPEC ending in a version number? > > > Or is something wrong with how we roll security/openssl/? > > > > LIB_DEPENDS += security/openssl/1.1>=1.1.1m,<3 > > > > has the intended effect and packages fine, so maybe I was just misusing > > LIB_DEPENPDS or misunderstanding packages-specs(7). > > > > Still seems odd, though, since the too high/low versions come from other > > package paths and not security/openssl/1.1, so why would it find > > openssl-1.0.2 or openssl-3.0 in the first place? > > > > Sorry for the noise in case I'm just missing something obvious here. >
You can put whatever specs you want, stuff like security/openssl/1.1>=1.1.1m,<3 is just a shorthand. Internally, it gets expanded into STEM->=1.1.1m,<3:security/openssl/1.1 (and then STEM gets converted into whatever the stem for security/openssl/1.1 is before getting into the pkg args). there is nothing that prevents writing the exact pkgspec you want as a first part: foo-0.0|bar-0.1:some/path will work just fine. It's just not necessary 99% of the time.
