Re: multi-variant packages and bulk builds

[Aleksey Cheusov <cheusov%tut.by@localhost>]

> You are mixing two different problems:

> 1.  Knowing exactly all the parameters that influence the build of a
>     given package.
... and changes package's PKGNAME

This is significant. I hope it is always true for php/python/apache modules.
Otherwise this is a problem and it should be resolved.

>     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.
The goal is to generate binaries for all valid combinations
of apache/php/python. And a list of all possible combinations
in the variable VARIANTS allows me to do this.

>     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.
Whether py23-xxx, py24-xxx and py25-xxx packages conflicts
or not is a completely different question. My proposal and this
problem/question are completely independant.

>  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.
I didn't even try to talk about options framework. Again, my proposal
and options framework are completely independant
unless you reimplement php/apache/python
variations through options framework or something more powerful
combining both php/python/apache and options framework.

At this time option framework is outside of my interest and
I'm talking only about php/python/apache modules.

But you directs me to the following thought:

VARIANTS variable I proposed does the same thing for
php/python/apache/emacs?/something_else? as 'make show-option' does
for options framework. They are full analogs.
This is yet another reason why it is good to have it.

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

>     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.
Lets speak about option framework and VARIANTS differently.
My proposal doesn't relate to options at all.
I think it is possible for me to adapt distbb to
build ALL packages with ALL combinations of ALL options.
But this is not thing I'd like to discuss now.

> 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.
Oh :-( I'll try to explain once again why I don't want to do the same
things as pbulk/Joerg did.

There are three reasons.

A)

  1) One of the basic principle in programming is "do not copy-paste".
   Do not copy-paste big parts of code, do not copy-paste functions,
   classes, files etc. In general, do not copy-paste repeateable things,
   especially in case such things can easily be changed. Instead,
   separate such things into a separate substance, and then call
   this SUBSTANCE by its NAME. I hope all of you are familiar with
   this simple rule.

  2) In our case "repeated thing" is a list of variables by changing which
   we can build all variants of python/apache/php-based modules.
   These variable are PYTHON_VERSION_REQD, PHP_VERSION_REQD
   and PKG_APACHE_REQD.

   (My patch probably needs to be fixed. s/_DEFAULT/_REQD/ )

   A list of these variable MAY CHANGE in the future.

  3) Another "repeated thing" is a list of variables that keeps
   valid/accepted versions of php/python/apache for any particular
   package.

   These vars are: _PYTHON_VERSIONS_ACCEPTED, PHP_VERSIONS_ACCEPTED
   and PKG_APACHE_ACCEPTED.

   This list may also change in the future.

  4) These two lists are repeatable because they are used (directly
     or indirectly) in at least pbulk, my distbb, again my pkg_summary-utils
     (in pkg_online) and who knows 'make all-packages'.

     I think Four examples are enough to proof "repetition".
     Even two (pbulk and distbb) are enough.

  5) Items 1-4  =>  I ask you: Do not copy-paste these lists over many tools,
     separate them
     into a new substance and NAME it. BTW, I don't insist on the name
     VARIANTS, if you have better idea, rename it...

B) Currently there is no analog of 'make show-options'
   for php/python/apache modules. And I thing VARIANTS variable is
   good candidate for it.

C) There are some people which think that existence of my distbb is
   good thing even if it is not official tool. They said something like
   "competence is good, let's see". If you/they really think so,
   pleeeeeeeeeeease add VARIANTS variable to pkgsrc or implement 
   similar functionality in any other way (I need FUNCTIONALITY).

   I hope pkgsrc developers are not against third party software.
   Is it SO HARD to add so small functionality to pkgsrc
   really needed by third party software? While developing distbb
   I NEVER asked you to extend pkgsrc API before, because it is
   enough in most cases.

   I tried to use your pbulk because I'm tired of it, sorry.  I don't
   use it anymore and I will not use it in nearest future.

   Also note, that I'm not the only person who uses distbb and
   binary packages it creates. I/we also need better support
   binary repository.

-- 
Best regards, Aleksey Cheusov.