On 2007/10/26 01:27, Enache Adrian wrote:
There was, simply put, no need for you to do it.
I did that in part because it's easier to work within the structure.
Stuart mentioned most of the advantages, but "make update-patches" is
the big one - it saves all the changes in a standard way, making it
possible for others to "repeat the experiment".
Test it thoroughly first, then care about the portage red-tape.
Testing is in progress.
Stuart wrote:
What you see as red tape, others see as a method of quality
control.
To test things thoroughly, you usually need more than one person.
...
To have more than one person testing software, those other people
need to be able to repeat the same installation. Otherwise it won't
be clear whether a problem is because someone didn't successfully
work out the correct meaning of your words, or whether it's a
problem with the code, and so it won't be a valid test.
Right!
When it's tested and working, then it's possible to deal with
the real red-tape (like, whether it should be in a standard build
or as a FLAVOR, etc)...
Chris Kuethe wrote:
> I think the right place to wire this in is emulators/qemu, as a flavor
> (or maybe a subpackage) that only shows up on amd64 and i386. Qemu
> still works with full software emulation if the module is not loaded
> or the user doesn't have permission to open the device; making kqemu a
> subpackage rather than an entirely different flavor is probably the
> best option.
Except that qemu and kqemu are different programs with different
distfiles and different release cycles.
My thought was a Qemu flavor qemu-kqemu (or qemu-accel) which
would have a run-depends on a separate kqemu port.
