[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: binary pkg "variants" ? [was: Re: Package split or package options?]
I am concerned about how this will affect our ability to correctly
produce patterns for the pkg-vulnerabilities file (used by
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.
On Sun, Mar 30, 2014 at 2:18 AM, Alistair Crooks <agc%pkgsrc.org@localhost>
> 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.
Main Index |
Thread Index |