On Tue, May 06, 2008 at 07:05:22AM -0400, John Peacock wrote:
> It also occurred to me now that this feature is going to make the package
> maintainers crazy, because now they have to have a svn-with-gnomekeyring
> and svn-without-gnomekeyring packages, that will necessarily conflict with
> each other.
It's not that uncommon to have compile-time dependencies.
All major *nix systems I've heard of have at least some
semi-smart way to deal with that.
But you have a point, of course -- it's not as beautiful as
making it work automagically without any knobs involved.
> Could this possibly be implemented as a module so that the
> core only has the necessary hooks and the plugin has the actual keymanager
> support? Then it becomes package/subpackage and it won't require much
> duplicated effort. Having this feature be predicated by a compile-time
> option is a bad design choice, IMNSHO...
Making it a compile option makes sense while developing the feature.
It prevents others from having to install the corresponding
libraries once the feature hits trunk, but allows people to test
it easily.
Making the feature a module is a desirable goal, but should not
be confused with getting the feature to work in the first place.
Also, kwallet seems to hit more difficulties here than gnome-keyring
because the C/C++ conundrum. Until we find a suitable solution
to deal with that at runtime, making it a compile time option is
better than not having the feature at all. Distro packagers are
still entitled to simply not compile kwallet support in if it is
too much of a burden for them. It's not that big of a deal.
Stefan
--
.sig free!
- application/pgp-signature attachment: stored
Received on 2008-05-06 13:39:21 CEST