On Wed, May 7, 2008 at 12:44 AM, Branko Èibej <brane_at_xbc.nu> wrote:
> Stefan Sperling wrote:
>
> > 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.
> >
> >
>
> Oh bosh. I bet 2 months from now someone's going to conveniently forget
> this discussion and just leave the compile-time thing in. Then when package
> maintainers start screaming, we'll do this all over again. Such is the
> nature of open-source projects.
>
>
>
> > 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.
> >
> >
>
> Huh? So you want us to brag that "Subversion supports Gnome Keyring and
> Kwallet" and then add small print about how most package maintainers don't
> compile in either version because it's too much of a burden? Now that is a
> truly brilliant security strategy.
>
> Sorry if this is slightly sarcastic but what you propose is quite contrary
> to the purpose of the whole exercise.
Can we do this with DSOs like RA/FS modules? I think we already
support (optionally) building in such a way so that
ra_neon/fs_base/ra_serf can be installed separately (and only if their
prereqs exist)...
--dave
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
Received on 2008-05-07 02:23:38 CEST