[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  > grep
PKG_SUPPORTED_OPTIONS= inet6 libssh2 gssapi ldap rtmp libidn
[19:17:40] agc@netbsd-001 ...pkgsrc/www/curl  >
> >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:
+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?
Main Index |
Thread Index |