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

[Jonathan Perkin <jperkin%joyent.com@localhost>]

* On 2014-04-02 at 09:53 BST, Anthony Mallet wrote:

> On Wednesday, at 04:24, Alistair Crooks wrote:
> | On Mon, Mar 31, 2014 at 10:58:18AM +0200, Anthony Mallet wrote:
> | > In which context do you think this wouldn't scale properly?
> | 
> | [19:17:28] agc@netbsd-001 ...pkgsrc/www/curl [11626] > grep 
> PKG_SUPPORTED_OPTIONS options.mk
> | PKG_SUPPORTED_OPTIONS=  inet6 libssh2 gssapi ldap rtmp libidn
> | [19:17:40] agc@netbsd-001 ...pkgsrc/www/curl [11627] >
> 
> Sorry, I was not clear : I meant "what would not scale?".
> I have many packages in robotpkg with 6 options or more, and I have not had 
> any
> "scalability" issue.
> 
> Of course, if you're talking about the number of different binary packages 
> that
> can be generated, this does not scale. For instance, the ~300 packages in
> robotpkg can generate more than 9000 different binary packages in total. This
> is not tractable in pratice, but you don't want to generate all possible 
> binary
> packages. Typically, you build only the default options and for some packages
> a small set of "interesting" options combination.

I looked into this for a while at Joyent, and ultimately concluded it
wasn't worth the effort.  It's fine for a very limited set of packages
and package options if you are very careful, but you quickly run into
intractable problems.

The main issue is dependencies, as you now have to pull in the correct
binary package for the options involved, and how you express the
matching in bl3 or DEPENDS.

And as soon as you want to introduce any PKG_OPTIONS which are handled
by mk/pbulk/pbulk-index.mk then there is an explosion of combinations
and difficulties in matching the correct version required.

Given that I don't believe there is a way to solve these issues in the
general case, and that you will need to be very careful in the options
you allow to be supported, I don't see any advantage therefore in
simply just providing additional packages for those instances, and
this is the approach we will be taking.

-- 
Jonathan Perkin  -  Joyent, Inc.  -  www.joyent.com