Philippe Cerfon <philc...@gmail.com> writes: > On Sun, May 22, 2022 at 2:09 PM David Bremner <brem...@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/