> i think it's a good question but lacking time travel or a working
> 64-bit kernel, this question is unknowable. :-)
;-) After thinking about it I think amd might have been a better example
>> > please, no use flags. we can't test what we've got. use
>> > flags make the problem go factorial. (gentoo for example
>> > doesn't work if you set the profile use flag.)
>>
>> Now we are getting to the heart of a very important matter. I agree
that
>> use flags causes the dependency graph to go factorial -- but pruned to
>> the
>> number of use flags implemented in each ebuild (so it is not factorial
to
>> the number of accepted use flags).
>
> if each package has only n use flags, then you still have
> 2^n^m options, where m is the number of packages.
>
> proof: each use flag may be on or off. if we order the use
> flags for a package arbitrarly, we can think of them as binary
> digits and there would be 2^n possible values. since there
> are m packages, we can consider this an m digit number with
> each digit taking the value 0 ... 2^n-1.
>
> if they don't all have the same use flags, we can redo this.
> if for package k, there are k_n use flags we would have
> 2^{k_0}2^{k_1} ... =
> 2^(sum k_i}
>
> which i'll grant isn't factorial. but it's still 2^{sum of use flags
> per package}. :-)
>
> i'll give you that this isn't factorial. :-) but on the other hand,
> if a package might not be installed at all, that's like another use
> flag.
and without use flags I end up having k*m packages instead of m. So the
question still comes to do I write it to allow 2^n^m possible combinations
and document the two most common scenarios, or write 2*m package variants
and leave it to the interested to populate any of the remaining 2^{k-2}
permutations. I'm still undecided, but I know then kinds of bugs that
creep up when splitting trees like that. (I guess like splitting hairs ;-)
EBo --
