Re: binary pkg "variants" ?

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

On Tuesday, at 18:10, Ryo ONODERA wrote:
| From: Anthony Mallet <tho%netbsd.org@localhost>, Date: Tue, 17 Jun 2014 
10:38:02 +0200
| As pkgsrc developer, I create the pkgsrc packages that has many options,
| and I must preserve binary package tarball not to be overwritten by
| another binary package that is built with another option.
| As pkgsrc user, if binary packages are provided by options, it is
| very convenient.
| 
| I am not a professional programmer and I cannot say about efficiency of
| your program.
| What is efficiency/scalability in this case?

The main issue is that even for a small number of options, the number of
possible packages quickly explodes. And it is completely untracktable if you
also consider the cartesian product of the dependencies. So it will never be
possible to e.g. bulk-build all possible packages and packages combinations.

The approach that I have chosen is to stick to bulk building packages with the
default set of options only, except for a very few specific cases which are
specified manually.

What is not clear yet is the algorithm matching a package requirement against a
set of packages names. For instance, if you require foo>=1.0~a (package foo
with option a), is foo-1.0~a+b (package foo with options a and b) "better" than
just foo-1.0~a ? Which one should be used? And it becomes even more complex
when you want wildcards (e.g. foo>=1.0~a+!* - with option a but no other
option). The generic matching problem is called SAT and this is considered to
be an NP-complete problem, so I just implemented some heuristics that do work
for the most usual cases, but which are not formally defined...