On 01/06/2013 06:56 AM, Diego Elio Pettenò wrote:
> I forgot to mention that (a) is what the Ruby team has been doing up
> to now -- it feels a bit more cumbersome in some cases, but it's
> definitely easier to spot the problems from the start than finding
> them months after adding the package of
I forgot to mention that (a) is what the Ruby team has been doing up
to now -- it feels a bit more cumbersome in some cases, but it's
definitely easier to spot the problems from the start than finding
them months after adding the package of the tree.
Especially if you change your mind and decide t
I agree with "a".
A problem with "b" is: the user might install one of those "optional
dependencies" later, but that will not trigger a rebuild of the other
package and another run through the test phase.
I would find "c" a bit confusing.
The most elegant way would probably be to trigger a remerge
Go for a. The widest and more consistent the testing, the better.
Otherwise the day after tomorrow you'll get a bug from me that with
$foo installed, $bar fails tests.
Diego Elio Pettenò — Flameeyes
flamee...@flameeyes.eu — http://blog.flameeyes.eu/
On Sun, Jan 6, 2013 at 11:38 AM, Michał Górny
