Re: Compile-time optional Features
* Matthew Palmer (mpalmer@debian.org) wrote:
> 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.
This is indeed the path I would like to take especially in respect to
maildrop. I think the ldap support is something that really
differentiates maildrop from other MDAs...
> * 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.
That's an option I hadn't really considered. That does make a certain
amount of sense to try to get the maintainer to adopt it in stages.
> 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
> have.
I have offered my help and to even co-maintain the package in the
maildrop case.
> > 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.
Right, but if at all possible we should strive to make our packages as
feature-rich as possible because as soon as someone has to compile
there own packages, Debian's advantages go down (seemless upgrades,
security updates, etc.).
--
Eric Dorland <eric.dorland@mail.mcgill.ca>
ICQ: #61138586, Jabber: hooty@jabber.com
1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+
O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+
G e h! r- y+
------END GEEK CODE BLOCK------
Reply to: