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

[Anthony Mallet <tho%netbsd.org@localhost>]

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.

| > The first two patches are unrelated to options and are just code
| > refactoring. Maybe I can just commit these for now?
| > 
| > 
http://www.netbsd.org/~tho/0001-pkgtools-pkg_install-Factorize-code-adding-a-version.patch
| 
| Yes, re-factoring, but the re-factored code is less readable,
| understandable, and obvious than the previous code.  At a glance, I
| could see what
| 
|       pattern = xasprintf("%s-[0-9]*", pkgname);
| 
| did. The following:
| 
|       pattern = addpkgwildcard(pkgname);
| 
| is opaque. Moreover, the function itself where this is factored into
| is a one-liner:
| 
| +char *
| +addpkgwildcard(const char *pkg)
| +{
| +     return xasprintf("%s-[0-9]*", pkg);
| +}
| 
| so I don't see the benefit of it. Please explain why it's better...


This is better for the patch implementing the options in package name (see line
274 in
http://www.netbsd.org/~tho/0003-pkgtools-pkg_install-Introduce-the-tags-package-suff.patch
) and this groups in the single file opattern.c all the code manipulating
the package name format and assumptions about this format.

| 
| > 
http://www.netbsd.org/~tho/0002-pkgtools-pkg_install-Do-not-reinvent-pkg_match-for-m.patch
| 
| Not sure why this was there previously - perhaps for efficiency, not
| allocating and freeing memory on every invocation.  Perhaps joerg can
| shed some light?

Same reason: do not scatter assumptions about the package name format.