Re: binary pkg "variants" ? [was: Re: Package split or package options?]

[Tim Zingelman <tez%netbsd.org@localhost>]

I am concerned about how this will affect our ability to correctly
produce patterns for the pkg-vulnerabilities file (used by
audit-packages.)
We too often have a hard time getting all the patterns right, and
unless I misunderstand how this change to package names and new
matching will work this will make things significantly harder.
Perhaps an example will help me understand... If a package has 6
possible non-mutually exclusive options, 2 of which are default and
there is a vulnerability in the base package (with or without options)
how do we specify a pattern?  To be more concrete lets say the
vulnerability is found in versions of pkgname starting with version 4
and is fixed in pkgname-4.3.2nb1, and lets call the options aaa, bbb,
ccc, ddd, eee & fff, with bbb & fff being default options.  Prior to
these proposed changes we would use the pattern pkgname>=4<4.3.2nb1
I appreciate any assistance you can provide in helping me understand
the fine details here.

Thanks,

 - Tim

On Sun, Mar 30, 2014 at 2:18 AM, Alistair Crooks <agc%pkgsrc.org@localhost> 
wrote:
> On Sat, Mar 29, 2014 at 11:21:04AM +0100, Thomas Klausner wrote:
>> On Sat, Jan 18, 2014 at 03:28:52PM +0100, Anthony Mallet wrote:
>> > Here are the 3 patches for pkgtools/pkg_install implementing the 
>> > aforementioned
>> > naming scheme in robotpkg. As such, the patches are supposed to be 
>> > harmless,
>> > i.e. pkgsrc/pkg_install will work exactly as before (but of course 
>> > implement
>> > the necessary bits for the new naming scheme, mostly affecting pkg_admin 
>> > pmatch).
>> >
>> > Patches 1 & 2 are just code refactoring, patch 3 implements the real stuff.
>> > There is my git commit message in the patch, hopefully explaining what is
>> > implemented.
>> >
>> > http://www.netbsd.org/~tho/0001-pkgtools-pkg_install-Factorize-code-adding-a-version.patch
>>
>> Ok, commit this after the branch.
>>
>> > http://www.netbsd.org/~tho/0002-pkgtools-pkg_install-Do-not-reinvent-pkg_match-for-m.patch
>>
>> Good too.
>>
>> > http://www.netbsd.org/~tho/0003-pkgtools-pkg_install-Introduce-the-tags-package-suff.patch
>>
>> >From the patch age I assume you've been running this for years, so commit 
>> >this too please.
>
> Personally, I have my doubts about this - I really have problems with
> its scalability, and think, while it might work for one, or even two
> options, it doesn't scale up beyond that.
>
>> > Examples:
>> > pkg_admin pmatch 'x>=1.0~a' x-1.0 ->false
>> > pkg_admin pmatch 'x>=1.0~a' x-1.0~a ->true
>> > pkg_admin pmatch 'x>=1.0~a' x-0.0~a ->false
>> >
>> > pkg_admin pmatch 'x~!a' x-1.0~a ->false
>> > pkg_admin pmatch 'x~!a' x-1.0 ->true
>> >
>> > pkg_admin pmatch 'x~a+b' x-1.0 ->false
>> > pkg_admin pmatch 'x~a+b' x-1.0~a ->false
>> >
>> > pkg_admin pmatch 'x~*' x-1.0 ->true
>> > pkg_admin pmatch 'x~*' x-1.0~a ->true
>> >
>> > pkg_admin pmatch 'x~!*' x-1.0 ->true
>> > pkg_admin pmatch 'x~!*' x-1.0~a ->false
>> >
>> > etc.
>> >
>> > Some remarks:
>> > - The matching algorithm with patterns on boolean variables is in general a
>> >   complex problem (known as SAT, I think), and the one implemented tries to
>> >   keep things simple and intuitve. But it's not been formalized, so there 
>> > must
>> >   be some caveats ...
>> >
>> > - As wiz@ already noted, the use of the not operator `!' might be replaced 
>> > by a
>> >   `^' to avoid quoting issues, and instead of using 
>> > pkgname-version~options,
>> >   one could also use pkgname~options-version?.
>
> I have only ever seen ^ used as a negation or complement operator at
> the start of character classes in regexps, which I think is an
> esoteric case.  I also don't think that quoting should have any
> bearing on this.
>
> I'd prefer to see more discussion before anything gets committed.
>
> Best,
> Alistair