Re: Compile-time optional Features
On Mon, May 10, 2004 at 12:50:36AM -0400, Eric Dorland wrote:
> Now neither patch was really rejected out of hand by the maintainers
> but both were concerned by feature-creep and having to maintain N^2
> packages to support every feature. While I understand this reluctance
> to some degree I'm curious what other developers have done in similar
> situations? What kind of trade offs do you make between features and
> dependency-creep? Do we have an obligation to our users to enable the
> features they ask for?
I'd consider any one of the following three scenarios (in no particular
order of preference), depending on exact circumstances:
* Separate binary package. Useful if that feature and another couldn't
co-exist in a single binary, and both forms were useful to someone. Better,
of course, would be rewriting to allow both to exist (so we can move onto
the next option), but if that's too difficult, it's certainly a practical
one. It bloats the Packages file, unfortunately, and it already takes a
long time to process the packages list...
* Add feature into existing package. This would either be as an extra
configure option or, in extreme circumstances, a separate binary or wrapper
of some sort to make the appropriate functionality work. I would consider
this especially if there was likely to be use on the one system for all the
different features at different times. The problems are that you get giant
binaries, and bugs. I've enabled features for users on the condition that,
should a bug appear in that part, they are willing to help solve the
problem, as I have no understanding or interest in that part of things.
Seems to work OK.
* Make it excruciatingly easy to rebuild the package to support the optional
feature. This is something that I've not seen done much, but the idea is to
basically make it "point-n-drool" easy (almost, anyway) to rebuild the
package to suit the user's local needs. This is of particular importance
for packages that have large numbers of optional bits and bobs of use to
about 4 people - but of crucial importance to both of them.
On my own, I'm pretty casual about adding things - if people want an added
feature, I'll build it in, on the (abovementioned) proviso that my first
reaction may be to remove the feature rather than try and fix it if there
are major problems (modulo, of course, submitter and upstream assistance).
Bloat in binary packages isn't a giant problem, practically speaking - there
are already some almightily massive packages out there that people need to
> In the case of #222421 especially, I feel Josip is sort of dragging
> his feet on the issue. The bug asks to enable ldap support in
> maildrop. Since libldap2 is a priority important package, it is almost
> certainly installed on the system anyway, so enabling this support
> would not bring in any more dependencies. I realize this not a
> critical issue, but what do we do when useful feature XYZ is not
> included because the maintainer does not deem it important?
Convince them that it is important. If they're firmly entrenched and won't
change, produce a "trivial rebuild" patch and get them to apply that. Worst
case scenario is you maintain a feature patch which you apply alongside
package upgrades. Not the best solution, but I keep several packages on
local maintenance myself because I've got special needs, and I think that
most admins of real-world systems are probably in similar positions.