Re: multi-variant packages and bulk builds

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

> I fear this topic is more involved than you may think,
May be.

> Secondly, it may happen that changing a package's options may also
> change its API
I agree

> 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),
I used this notation just to demonstrate an idea ;-)
Nothing else.

> 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.
Your question was not clean for me and, in thruth, I still don't
understand what exactly you mean.

> Without these problems solved, I don't think it's sensible to
> provide binary packages for any other than the default options,
I didn't tell that I'm ready to discuss options framework and binary
packages for all option combinations.  The main and the only question I
had is at the very first mail in this thread - generalization for
building php/python/apache module. Thanks to Quentin Garnier
I realised that my proposal makes possible to BUILD all-options
binaries. And this is YET ANOTHER application for VARIANTS variable
and is yet another reason why it is good to have it.

What to do with all these binaries, how to name them, how to organize
ftp directory etc. are another questions and I'm not ready to discuss
this right now (and I didn't plan to do this at all). Again as was
said by Quentin, building "multi-option" packages (just building!) can
at least be used just for testing (at this moment).
No testing - no quality. Also note, there are some simple cases
when options do not lead to problems (e.g., changing API).

BTW, I'm not big fun of building options at all. I'm quite happy with
packages including "almost all" by default. So, I'm not the person who
will improve options framework. At least, not now.

To summarize, several different applications for VARIANTS approach
were demostrated. I showed several "why it is so important". Exactly
this was my REAL and the only request. IMHO availability to BUILD
multi-option package is very good benefit of VARIANTS and only this
availability whould be enough to implement VARIANTS' functionality.
But if everything I showed and said is not "proof", I just don't know
what to say, *shrug* :-(

-- 
Best regards, Aleksey Cheusov.