[bt-devel] RFC: Remove modules installed by the native package manager
Jonathan Marsden
jmarsden at fastmail.fm
Wed Apr 29 11:22:42 MST 2009
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.
> These are texts, documents and not programme modules.
There are, as I am sure you know, many other packages for Linux
distributions which are data packages, not program packages. SWORD is
not at all exceptional in that regard. Further, SWORD modules currently
need to be "installed", so they are rather unlike other texts and
documents which generally speaking do not require such installation.
Given that packaged SWORD data modules *do* exist, having front ends be
able to appropriately handle the existence of such packaged modules is a
clear benefit to their (our) users.
> No one is packing a few sample PDFs with evince.
When there are as many different SWORD modules in the world as there are
PDFs, and when SWORD modules do not need to be "installed", but are
simply a single document file in a defined and formally standardized
file format (maybe in a hypothetical SWORD 4.x, the underlying library
storage representation of a module might be a single OSIS 2.9.9 XML
file, with indexes being created and cached as needed??), *then*
packaging individual document files might be universally seen as totally
useless, and comparison with PDF would be a lot more valid.
For now, I suggest that we focus on the real world, in which such
packaged SWORD modules really *do* exist, and improve the end user
experience in that (possibly imperfect) world, rather than discuss a
hypothetical situation in which no such packages "should" exist :)
In that context, Sveinung's work is IMO a valuable contribution.
Jonathan
More information about the bt-devel
mailing list