[pkg-crosswire-devel] Fwd: sword-comm-mhc_2.0-1_amd64.changes REJECTED

[Teus Benschop]

On Sat, 28 Aug 2021 at 15:41, Roberto C. Sánchez <roberto at debian.org> wrote:

> On Sat, Aug 28, 2021 at 03:36:51PM +0200, Bastian Germann wrote:
> >
> > The downside of packaging the CrossWire modules is that they are not very
> > good at keeping their source updated to the same version that is
> published
> > as binaries on their FTP server. Also, the copyright information is
> > sometimes inaccurate, which is the case with the MHC module. Lafricain
> has
> > improved the situation a lot compared to what it was.
> >
> > I think, the baseline for our modules should be to meet Debian Policy.
> Two
> > of them will be autoremoved if the source does not appear in the next two
> > weeks, and I think that is okay.
> >
> > For the other modules, there are still #985655 and #985656, which are
> > actually also Policy violations and could have a higher priority. I do
> not
> > have experience of converting USFX/USFM to OSIS/Sword and there are
> several
> > programs out there that do that. The affected modules' source eBible uses
> > Haiola, but I think having that in Debian just for this reason will be
> too
> > much work. So, alternatively we could package usfm2osis (which version?)
> or
> > u2o. Any thoughts on this?
> >
> There is definitely an established pattern for packaging installer or
> helper scripts that perform the download, unpacking, etc. of components
> which for some reason cannot be directly packaged.  The msttcorefonts
> installer package is one that immediately comes to mind, but there are
> others.  This might be a good alternate approach, for providing modules
> and content in a system-wide way that is at least visible through the
> apt infrastructure.
>
>
> It could indeed save time for us all, as the package maintainers, to use
an approach that

1. requires the least amount of effort, and

2. that makes keeping a package up-to-date more automatic or intuitive.

It could be that packing the downloader scripts would be an alternative
approach, and/or removing text packages for Sword that require too much
work in the view of the maintainer.

I guess that whoever does the maintenance work on a package is completely
free to decide if and how and how much time to spend on these Sword text
modules.

Whatever approach the maintainer(s) pick, my main concern would be that
users always have access to text modules they need, and since they always
have access to that I would be happy with whatever course would be taken
with regard to maintaining or not maintaining these packages.