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

[Alistair Crooks <agc%pkgsrc.org@localhost>]

On Mon, Mar 31, 2014 at 10:58:18AM +0200, Anthony Mallet wrote:
> On Sunday, at 09:18, Alistair Crooks wrote:
> | 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.
> 
> 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] >
 
> >From my experience, packages seldom need complex dependency requirements
> regarding options, but I may be missing something.
> 
> | I'd prefer to see more discussion before anything gets committed.
> 
> 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...

> 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?

Thanks,
Alistair