Re: [9fans] nupas update

[EBo <ebo@sandien.com>]

> 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 --