Auto-variants

[Jeff Johnson]

On Aug 8, 2011, at 4:24 AM, Anders F Björklund wrote:

> Jeff Johnson wrote:
> 
>> There's likely a general problem with variants as well. Meanwhile
>> RPM has a tremendous number of "Have it your own way!" build options,
>> and when max-ed out can like 70+ libraries.
> 
> All libraries should be accounted for... This was about the paths
> to various runtime programs encoded into macros. Easy to edit, too.
> But one _could_ make sure that they only find the /usr variants…
> 

I should mention the packaging paradigm mapped onto "+variant" in
order to quibble with "accounted" for.

Every packaging system eventually needs a mechanism for choice. In
RPM these are called "build conditionals", there's analogues in rPatch
Conary and SuSE zypper and Debian Suggests: and even in NixOS (but
"functional" packaging is way different than usual "archiver" packaging).

These are all attempts to add a mechanism to support "choice". The
mechanism and syntax is the easy part, what is harder is attaching s sound
semantic to "+variant" that is both workable and useful:
	small name space consistently used in Portfiles
	attribute (rather than scoring) based modifier to dependencies
	
Mac Ports "+variant" is closest to Getting It Right! imho. The "+variant"
has evolved from its original usage (which was rather feeble) into
something fairly useful.

Sepcific points:

1) Attempting "+variant" on RPM AutoFu isn't simple: Let Anders do the "accounted for".

2) Other issues like "hidden dependencies" (likely real problems) are unrelated to "+variant" inheritance
and should be dealt with as a different problem.

73 de Jeff