Bug#824520: RFP: subsurface -- scuba diving logbook

[David Bremner <bremner@debian.org>]

Philippe Cerfon <philcerf@gmail.com> writes:

> On Sun, May 22, 2022 at 2:09 PM David Bremner <bremner@debian.org> wrote:
>> To be honest, I doubt that helps, since the hard part is not just making
>> packages (my repo on salsa already does that), but making them in a way
>> acceptable to debian policy, which is unlikely to be a priority for a
>> PPA.
>
> Were there any specific concerns in terms of policies left? subsurface
> seems rather simple to me, the only bigger point perhaps being the
> issue with libdivecomputer. But not since the "official" one is even
> gone from Debian, it shouldn't be to hard to make a point for a
> libdivecomputer-subsurface or so, when one could argue that this is
> really a fork and thus acceptable for Debian.

I have not looked very closely. Some issues I am aware of

1) As discussed, libdivecomputer. From subsurface INSTALL

        Subsurface requires its own flavor of libdivecomputer which is inclduded
        above as git submodule

        The branches won't have a pretty history and will include ugly merges,
        but they should always allow a fast forward pull that tracks what we
        believe developers should build against. All our patches are contained
        in the "Subsurface-DS9" branch.

        This should allow distros to see which patches we have applied on top of
        upstream. They will receive force pushes as we rebase to newer versions of
        upstream so they are not ideal for ongoing development (but they are of
        course easy to use for distributions as they always build "from scratch",
        anyway).

        The rationale for this is that we have no intention of forking the
        project. We simply are adding a few patches on top of their latest
        version and want to do so in a manner that is both easy for our
        developers who try to keep them updated frequently, and anyone packaging
        Subsurface or trying to understand what we have done relative to their
        respective upstreams.

1.5) Submodules are a pain for most Debian workflows (except those that
     ignore the git repo).

2) There is minified js in themes/