[Pkg-owncloud-maintainers] Nextcloud desktop client packaging

[István Váradi]

Hi,

On Fri, Jan 31, 2020 at 6:37 PM Sandro Knauß <hefee at debian.org> wrote:

> Hey,
>
> > I am maintaining a PPA for mostly beta and alpha Ubuntu packages of the
> > Nextcloud desktop client as well as ab OpenSUSE Build System repository
> for
> > Debian packages.
>
> Cool to actually get contact. Let's move the discussion to the maintainers
> list, as I'm not the only person that is packaging nextcloud-desktop for
> Debian.
>
> > Recently it has been reported that there is a clash  between the official
> > Debian/Ubuntu packages and mine due to some files placed in different
> > packages. Also, the name of the main package is different
> > ("nextcloud-client" vs "nextcloud-desktop").
> >
> > I think it would be useful to have common Debian build control files that
> > both of us work with. My files are in the upstream
> > repo's admin/linux/debian directory. As you can see there are slight
> > differences between the various distributions, so it is not as simple as
> > having a single debian directory in the repository's root directory.
> >
> > Do you think there is a way to unify the build control files that suits
> > both of us? It is OK for me to use your package structure (i.e. name the
> > main package "nextcloud-desktop", etc.), though of course transitional
> > packages should be provided in the PPA. But the differences between the
> > various distributions should be handled somehow.
>
> Packaging data is updated after Nextcloud released a version, so having
> the
> files inside the upstream repo is wired. Also we often need to apply
> patches on
> top of the releases, as they are not perfect. What Debian is doing is
> having a
> parent branch, that is the master branch of upstream and the master branch
> is
> actually an overlay with the Debian files. see [1]. From our side, the
> obvious
> step would be, that you publish your packaging data to our salsa
> repository
> and have branches for the different distribution.
> Also I do not understand how I should interpret the data under admin/linux/
> debian, as this is not standard Debian packaging style. Btw. the changelog
> in
> these directories refer to version 2.3.3 in the 2.6.1 release.
> If we have all data at one place we can start looking into the differences
> and
> properly find ways to unify stuff.
>

There is a "debian" directory under admin/linux/debian, which has the
standard Debian layout. And besides this "debian" directory, there are
other "debian.<distribution>" directories. When building a source package
for a certain distribution, the build script copies the "debian" directory
to the root of the source tree and then copies any files from the
corresponding "debian.<distribution>" directory over the copy of the
"debian" directory in the root of the source tree. This way the standard
Debian layout is created and the source package can be built. The
"debian.<distribution>" directories thus serve as a klnd of simple
"patches".

The changelog is automatically generated from the commit messages (starting
from a certain commit) and the result is prepended to the "changelog" file
in the repository.

An automated build is performed for each commit merged to the upstream
master branch and one should also start for the stable branches, which is
not triggerred currently, but it should (so I trigger it by handÖ :)
Anyway, the solution we find should support this use case. Storing the
packaging data in your repository in different branches could work, as the
build script could fetch the salsa repository and use the "debian"
directory from ther appropriate branch. The situation is somewhat
complicated by the requirement that one should be able to build both the
master and the current stable branch, where the packaging data could
differ. So perhaps occasionally distribution-and-upstream-branch-specific
branches should be created if that is OK with you.

That said I think this having to support multiple upstream branches is a
strong reason for storing the debian packaging data in the upstream
repository, if it could suit your build workflow. I am aware that at some
point the standard Debian directory layout must be present, but couldn't
you perform a similar copy operation during your build process?

István


> hefee
>
> [1] https://salsa.debian.org/owncloud-team/nextcloud-desktop
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-owncloud-maintainers/attachments/20200131/064e5d34/attachment.html>