Re: multi-variant packages and bulk builds

[Dieter Baron <dillo%KD119105101110.ppp-bb.dion.ne.jp@localhost>]

In article <20080723135801.GA25250%taryn.cubidou.net@localhost> Quentin wrote:
: [-- text/plain, encoding quoted-printable, charset: us-ascii, 114 lines --]
: You are mixing two different problems:

: 1.  Knowing exactly all the parameters that influence the build of a
:     given package.

:     The {PYTHON,PHP,APACHE}_ACCEPTED variables are used to know if you
:     can build a package in a given environment.  While there may be a
:     point in having a framework to handle multiple versions of packages,
:     the goal is not to make a list of all possible combinations.

:     Either the user controls his environment and sets the appropriate
:     variables to set the specific version of such pieces of software she
:     wants, or lets pkgsrc decide, using the _DEFAULT values.

:     Back in pkgviews days, you could have multiple versions of a package
:     in the same installation, but that approach ultimately failed
:     because in the end it wasn't that much simpler than having several
:     LOCALBASEs.

:     What I feel is missing currently is a way for the user to retrieve
:     the information about version dependencies.  A lot of effort was put
:     in the options framework with great success, and my humble opinion
:     is that such information ("I will build with apache22, per your
:     environment" or "I will build with php5, per pkgsrc's default")
:     belongs in "make show-options", even though this is slightly
:     different from a regular option.

  That sounds like a good idea.  I would also like it to include all
user settable variables the package uses, including their default
values (which currently is impossible, since the user setting
overwrites the defaults).

: 2.  Providing binary packages for all the world and its mother.

:     Here I think both pbulk (iow, Joerg) and you are wrong.  pkgsrc's
:     flexibility is both its greatest asset and its curse.  From the
:     administrator's point of view, the options framework and the
:     support for different versions of PHP, Apache and Python is an
:     amazing feature.

:     However, it is also part of the reason why our binary package
:     distribution (actually, the lack of a proper one) is pkgsrc's
:     greatest weakness.  Distributing the results of a bulk build is
:     easy, but maintaining a binary distribution over the time is where
:     we're not to the level of competitors.

:     A binary packages distribution has to be seen as a whole, with a
:     set of default options and settings that are consistent across all
:     packages.  Red Hat, Debian and whoever else provide you with a
:     static binary distribution, because that's the only way they can
:     sanely maintain and support it.

  I disagree.  The main reason people don't use binary packages is
that they disagree with the default settings; that the tools lack
functionality is only second on the list (at least that is the
impression I got from user's feedback).

 We can do this reasonably well when building from source, and I see
no reason we can't do this just as well when installing from binary
packages.  The basic problem of figuring out what to install is the
same.

  Yes, our binary package administration tools suck, and supporting
multiple conflicting variants in one binary package repository
increases the demands on our tools, but the problem is not impossible
to solve.

:     That said, there are different uses of bulk package building:  I
:     covered the user-oriented one, for which I oppose the idea of
:     building multiple versions of a package, with the exception of the
:     case where they don't conflict, in which case they should have their
:     own package directory anyway.  As for packages depending on any
:     version of another package, they should only be built for the pkgsrc
:     default version.

:     The other use of bulk building is for testing purposes, in which
:     case your VARIANTS idea could have merit.  The problem is, if you
:     want to test all building possibilities of a package, you also have
:     to test all subsets of the options list from the options framework.

  Actually, building with multiple option settings is on the TODO
list.  Not all combinations, just a pre-determined subset (by the
package maintainer).

:     I'll leave as an exercise to the reader to compute how many times
:     mplayer and mencoder would be built if we made pbulk or any other
:     bulk building system do all possible options combinations.

:     The point is, if you really want to formalise that part, you'd
:     better go all the way, and I really wish you good luck with that.
:     As for me, I think pbulk is already exceeding its expectations in
:     allowing such possibilities, and while pbulk can do whatever it
:     wants in its world, there is no point is pushing that feature into
:     pkgsrc.

  I think we should go exactly as far as we want to produce binary
packages, since that is what this is for.

                                        yours,
                                        dillo