Re: [meiwaku] binary pkg "variants" ?

[Ryo ONODERA <ryo_on%yk.rim.or.jp@localhost>]

Hi,

Another freeze has started...
What is the stopper of this change.
If there is no stopper, please commit just after freeze end.

Thank you.

From: Anthony Mallet <tho%netbsd.org@localhost>, Date: Sat, 18 Jan 2014 
15:28:52 +0100

> On Thursday, at 10:48, Anthony Mallet wrote:
> | On Wednesday, at 20:56, Fredrik Pettai wrote:
> | | I noticed the way MacPorts done it and it looks reasonable ok. They name 
> the
> | | package "variants" as: pkgname @version+option(s). Perhaps pkgsrc could 
> name
> | | those alternative bin pkgs as: pkgname+option(s)-version ?
> | 
> | I also did that in robotpkg (http://robotpkg.openrobots.org), which is a 
> fork
> | of pkgsrc (targetting more specific goals and users and packages, hence the
> | fork).
> | 
> | Binary packages are named according to the following scheme:
> |  ${PKGBASE}-${PKGVERSION}~${PKG_OPTIONS}.tgz
> | 
> | $PKG_OPTIONS are joined with the "+" char.
> 
> Hi,
> 
> So.. back on this topic!
> 
> 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
> http://www.netbsd.org/~tho/0002-pkgtools-pkg_install-Do-not-reinvent-pkg_match-for-m.patch
> http://www.netbsd.org/~tho/0003-pkgtools-pkg_install-Introduce-the-tags-package-suff.patch
> 
> 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 also provide an *untested* example patch for mk/bsd.pkg.mk that changes the
> naming of the packages so that the ~options 'tag' is appended to PKGNAME. This
> might possibly break pkgsrc in some places, but the patch is mostly here to
> give you a concrete idea of the (almost only) change I did in robotpkg.
> 
> http://www.netbsd.org/~tho/PKGNAME.diff
> 
> Next step would be to review the places where this will break, but a
> technical/philosophical discussion about all this must probably take place
> beforehand. IIRC there was almost no issue when I did that in robotpkg, but 
> the
> code has diverged quite a lot from pkgsrc in some places, so I cannot tell
> precisely right now.
> 
> So ... what do you think :)
> 
> --
> Footnotes
> ¹ In robotpkg I have a shell script converting .tgz bsd binary package into
> .deb ones (dpkg), and I had to name the .deb packages according to the second
> alternative (i.e. pkgname~otpions-version), because dpkg is much more
> restrictive about the name of the packages.

--
Ryo ONODERA // ryo_on%yk.rim.or.jp@localhost
PGP fingerprint = 82A2 DC91 76E0 A10A 8ABB  FD1B F404 27FA C7D1 15F3