Re: multi-variant packages and bulk builds

[Dennis den Brok <d.den.brok%uni-bonn.de@localhost>]

Aleksey Cheusov <cheusov%tut.by@localhost> schrieb:
> When you say "to organize" you mean dependancies between
> packages having options?
>
> First of all, all options should be splitted into two categories.
>
> Category 1: options with GLOBALLY THE SAME SEMANTICS,
>    that is option with the same semantics for ALL packages.
>
>    For example, disabling -x11 option should ALWAYS mean
>    "no X support at all", and disabling -ssl option should ALWAYS
>    mean "no ssl support at all" for ALL packages.
>
> Category 2: options meaning different things for different packages.
>    Solutions:
>     a) avoid options of this category at all. That is, all package-specific
>        options MUST have a uniq name.
>     b) mark such options somehow and use this marker.
>
> After this, I presume dependancies can be set relatively easily.
> If, say, package A depends on package B and both they have option, e.g. x11,
> then binary package A-version%x11.tgz depends on  B-version%x11.tgz
> and package A-version%nox11.tgz depends on B-version%nox11.tgz.
> In this example I assume that option x11 is of "category 1".
> Here % is a char-separator between "old plain PKGNAME" and options part.

I fear this topic is more involved than you may think, at the very
least if you want to maintain maximal flexibility for consumers of
binary packages. But read on and, hopefully, prove me wrong.

Firstly, a user obviously may not want to choose either X11 or no
X11, but do so on a per-package basis. Ghostscript comes to mind
as an example.

Secondly, it may happen that changing a package's options may also
change its API, in which case one would have to build at least the
direct dependants once for each of the original package's options.
Putting aside whether naming the binary packages as you suggest
(which AFAIR has been discussed once on tech-pkg@, where the
consensus seemed to be that this naming scheme is too clumsy), this
is a waste of resources on the one hand and brings up the question
of how to sensibly organize the resulting binary packages on, for
instance, an FTP directory (which is what I meant when I posed my
original question), on the other hand.

Without these problems solved, I don't think it's sensible to
provide binary packages for any other than the default options,
inconvenient though this might be (who else wants modular xorg to
be the default, finally?).

--
Dennis den Brok