tech-pkg archive

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

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

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


Not sure why this was there previously - perhaps for efficiency, not
allocating and freeing memory on every invocation.  Perhaps joerg can
shed some light?


Home | Main Index | Thread Index | Old Index