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

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

On Wednesday, at 10:26, Jonathan Perkin wrote:
| The main issue is dependencies, as you now have to pull in the correct
| binary package for the options involved, and how you express the
| matching in bl3 or DEPENDS.

Most of package options don't actually modify the dependencies. Of course, some
of them do. This is handled in robotpkg by the equivalent pkgsrc-like code:

Suppose a package has an option 'foo' that requires a dependency on bar built
with the foo option :

   .if !empty(PKG_OPTIONS:Mfoo)
   . include "../../category/bar/buildlink3.mk"
     BUILDLINK_API_DEPENDS.bar+=  bar~foo
   .endif

The buildlink3 would define the dependency on bar (as usuall) and there is just
an additional line expressing the required 'foo' option on the bar package.

Then, the dependency resolution code merges the two requirements, for instance
if BUILDLINK_API_DEPENDS.bar ends up with the following two elements "bar>=42
bar~foo", they are merged into "bar>=42~foo", which is satisfied by any bar
package >=42 with the option foo enabled.

| And as soon as you want to introduce any PKG_OPTIONS which are handled
| by mk/pbulk/pbulk-index.mk then there is an explosion of combinations
| and difficulties in matching the correct version required.

Yes, there is an explosion if you want everything and this will definitely not
work. But, as I said, you don't want to build everything. I use a (very simple)
awk script that is able to expand lists like "foo~x11 foo~!x11" to for instance
build packages with and without x11, with all other options to their default
value.

| Given that I don't believe there is a way to solve these issues in the
| general case, and that you will need to be very careful in the options
| you allow to be supported, I don't see any advantage therefore in
| simply just providing additional packages for those instances, and
| this is the approach we will be taking.

The problem is mainly the conflicts on the filesystem of the binary package
names. You have to setup separate repos, duplicate many things. You cannot
verify that two given binary packages are compatible in terms of options, and
you cannot easily upgrade from one set of options to another set (e.g. with
pkgin).