<div dir="ltr"><div>Hi,</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jan 31, 2020 at 6:37 PM Sandro Knauß <<a href="mailto:hefee@debian.org">hefee@debian.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hey,<br>
<br>
> I am maintaining a PPA for mostly beta and alpha Ubuntu packages of the<br>
> Nextcloud desktop client as well as ab OpenSUSE Build System repository for<br>
> Debian packages.<br>
<br>
Cool to actually get contact. Let's move the discussion to the maintainers <br>
list, as I'm not the only person that is packaging nextcloud-desktop for <br>
Debian.<br>
<br>
> Recently it has been reported that there is a clash  between the official<br>
> Debian/Ubuntu packages and mine due to some files placed in different<br>
> packages. Also, the name of the main package is different<br>
> ("nextcloud-client" vs "nextcloud-desktop").<br>
> <br>
> I think it would be useful to have common Debian build control files that<br>
> both of us work with. My files are in the upstream<br>
> repo's admin/linux/debian directory. As you can see there are slight<br>
> differences between the various distributions, so it is not as simple as<br>
> having a single debian directory in the repository's root directory.<br>
> <br>
> Do you think there is a way to unify the build control files that suits<br>
> both of us? It is OK for me to use your package structure (i.e. name the<br>
> main package "nextcloud-desktop", etc.), though of course transitional<br>
> packages should be provided in the PPA. But the differences between the<br>
> various distributions should be handled somehow.<br>
<br>
Packaging data is updated after Nextcloud released a version, so having the <br>
files inside the upstream repo is wired. Also we often need to apply patches on <br>
top of the releases, as they are not perfect. What Debian is doing is having a <br>
parent branch, that is the master branch of upstream and the master branch is <br>
actually an overlay with the Debian files. see [1]. From our side, the obvious <br>
step would be, that you publish your packaging data to our salsa repository <br>
and have branches for the different distribution. <br>
Also I do not understand how I should interpret the data under admin/linux/<br>
debian, as this is not standard Debian packaging style. Btw. the changelog in <br>
these directories refer to version 2.3.3 in the 2.6.1 release.<br>
If we have all data at one place we can start looking into the differences and <br>
properly find ways to unify stuff.<br></blockquote><div><br></div><div>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".</div><div><br></div><div>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.</div><div><br></div><div>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. </div><div><br></div><div>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?</div><div><br></div><div>István</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
hefee<br>
<br>
[1] <a href="https://salsa.debian.org/owncloud-team/nextcloud-desktop" rel="noreferrer" target="_blank">https://salsa.debian.org/owncloud-team/nextcloud-desktop</a></blockquote></div></div>