> i've tried to make this point several times before.
> i think it is an error to envision what somebody
> might want.  build want you want.  respond to
> complaints.  do not build stuff speculatively.

Thank you for your clarity.  I was hoping to open a discussion and get
some feedback so when I do my thing it would likely be more useful.  When
starting new projects I typically start with a basic idea, then take it to
what I call its illogical extreme, and then whittle it back down to the
initial project.  It is part of how I get a handle on what the scope of
work looks like.  I guess that approach is in error for 9fans, but it works
quite well for me personally.  

>> Another potential use flag or architecture keyword covers if the
package
>> can be built, or should build, using 64 bit mode.
> 
> there is no 64 bit kernel.

Will there ever be?  Or is that even an appropriate question?

> 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).  The situation I am dealing with regards
to TinyCoreLinux is that they require that the documentation and source be
broken out into separate packages.  So, I have currently implemented this
as separate portage ebuilds for convenience.  But to make this work
generally, and for long term maintainability, I have to either implement
them as 3*packages or implement this as a "doc source" use flags and
possibly an independent ROOT.  The advantage of use flags here is that the
source and documentation build is kept together.  The disadvantage is that
building in use flags increases the complexity somewhat, but is it more
than what is saved by including them?  I do not know.  If I do implement
use flags I only see the need for maybe 3 or 4, at least for my uses.  I've
been bitten in the past by separating parts of a logical package at the
package level, but seperate source/docs are required, and I see how this
will make things easier when I have time to play with embedded systems
again. 

But this discussion demonstrates my point exactly.  If I had not opened
the discussion we would not have had the above exchange.  I would have
simply implemented something with use flags and then when you objected
later and I would unlikely be willing to rip it out without really good
cause or motivation.

  Best regards,

  EBo --

Reply via email to