[bt-devel] RFC: Remove modules installed by the native package manager

Greg Hellings greg.hellings at gmail.com
Sat May 2 23:12:31 MST 2009

On Sun, May 3, 2009 at 1:06 AM, Jonathan Morgan <jonmmorgan at gmail.com> wrote:
> Note: This is not a comment on the patch in question, which I do not
> care whether it gets included or not.
> On Thu, Apr 30, 2009 at 4:22 AM, Jonathan Marsden <jmarsden at fastmail.fm> wrote:
>> Peter von Kaehne wrote:
>>> My considered and often stated view is that this should not happen.
>> The fact remains that such modules do exist.  And there are people in the
>> world who, unlike you,  feel that packaged SWORD modules do in fact have
>> their place -- as evidenced in part by the very fact that such modules exist
>> :)  Since many SWORD modules are explicitly public domain, there is no way
>> to "force" packaged SWORD data to cease to exist, even if everyone on this
>> list fully agreed with your viewpoint.
> It seems very curious that software developers should be held
> responsible for their software not working as well when it is packaged
> in a way that they have strongly and expressly stated should not
> happen and is unsupported.

Agreed.  SWORD and its front-ends already have well-designed, well
documented and easily available means of installing, removing and
handling of module data.  To make us responsible for people using
means outside of our provided means is a bit over much.  There is no
need to provide that extra support - we have a method for it that is
actually much simpler than that "if SWORD Modules are ever one file"
hypothetical situation... the user doesn't even have to know if files,
databases or carrier pigeons are involved.  They just have to select
the ones they want for installation or removal.  Adding support for
various package managers introduces unnecessary complexity or bulk -
what if we don't support someone's chosen packaging mechanism? Is that
now our bug, or the external library's lack of feature or is it just
unsupported?  Big can o' worms here, IMO.


> Jon
> _______________________________________________
> bt-devel mailing list
> bt-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/bt-devel

More information about the bt-devel mailing list