To package or not to package?
Dear all,
I jump in the discussion to react to Zack's point of view about
packaging:
> However, in many cases, free software developers tend to reinvent the
> wheel quite often (so two apps can share the exact same goal and have
> very similar designs, the only difference being that one is of less good
> quality than the other). It's generally a bad idea to package both
> apps in this case, because it increases the workload, reduces the
> users-per-package ratio, etc.
In the field I decided to cover, I took another approach: packaging A
but not B biases the competition towards A, although I do not feel able
to make a choice between A or B which would be logical and fair.
Therefore, I try to cover the field as extensively as possible,
packaging DFSG-free software by default and telling the users that
non-free software will only packaged upon request.
(http://wiki.debian.org/SequenceAlignment)
With all packages performing the same task being equally available, I
expect natural selection to happen based on other criteria: popularity,
speed, accuracy, simplicity.
With the expected increase of popcon after Etch release, I am eager to
monitor the ecosysem and test in real wether my expectations were naive.
Have a nice day,
PS: Feel free to CC as I am not subscribed.
PPS: The web archive provides the message-id, to set In-Reply-To
correctly by hand.
--
Charles Plessy
Debian-Med packaging team
http://charles.plessy.org
Wako, Saitama, Japan
Reply to: