[Pkg-owncloud-maintainers] Nextcloud desktop client packaging

[Sandro Knauß]

Hi,

> 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".

Okay, well in order to handle this in a Debian known way, you should translate 
this to different branches.

> 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.

mmh I see, but than you don't need to ship different changelogs for different 
distributions. If the rest of the package data is not changed.

> 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.

You can have different upstream branches if you update the upstream-branch in 
debian/gbp.conf for the different branches, but you already need to touch that 
file to update the master-branch.

So in my mind we would end up in branches something like this:

ppa-nextcloud/debian/buster/{stable,master}
upstream/ppa-nextcloud/buster/{stable,master}

so you are able to control everything and we can even use the salsa ci to test 
packages.

> 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?

well there is also a Debian layout, where the upstream data is not part of. 
But this has also a lot of disadvantages, as I can't easy cherry-pick upstream 
patches into Debian. 

Instead of coping stuff around, you can use the current layout you simply merge 
upstream master into the debian branch, update the version and 

gbp buildpackage --git-force-create

and boom done ;) So you see it is possible to support your usecases.

hefee
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://alioth-lists.debian.net/pipermail/pkg-owncloud-maintainers/attachments/20200212/4968f573/attachment.sig>