[Pkg-owncloud-maintainers] Nextcloud desktop client packaging

[István Váradi]

Hi,

On Wed, Feb 12, 2020 at 11:51 PM Sandro Knauß <hefee at debian.org> wrote:

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

I build only source packages and upload them to Launchpad where the actual
build takes place. To be able to indicate which distribution the source
package is uploaded for, its version must end with a tilde followed by the
distribution's name (e.g. ~bionic, see
https://help.launchpad.net/Packaging/PPA/BuildingASourcePackage). AFAIK,
the version comes from the changelog file only, or is there a better way to
use the same changelog for different distributions?


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

OK, it seems that this branching approach could work.


>
> > 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.
>
>
I want to keep the build as much automated as it is nows. Currently each
merge to the master branch triggers a new build in the Drone system of
Nextcloud. I would also like to extend to any stable branches as well, but
the only issue with that is that the current Drone setup does not trigger
builds on branches, neither for tagging. However, as far as the
current build script goes, it should work.

Now, let us consider, say, the master branch only. After a major release,
the version number is stepped there and then several builds are made for
that version for each new merge. The build system creates only source
packages, which are then uploaded to Launchpad and the real building
happens there. For a certain main version (like 2.7.0), each source package
should be based on the same orig tar, because it can be uploaded only once
to Launchpad. This means that there are an increasing number of changes
between that orig tar and the actual code. The way I solve it in the
current build system is to run the command:

    EDITOR=true dpkg-source --commit . local-changes

before the build. With gbp it seems that I can do this with:

   gbp buildpackage --git-prebuild='EDITOR=true dpkg-source --commit .
local-changes'

Is this the correct way to do it, or is there a better way?

Istvan


> hefee
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-owncloud-maintainers/attachments/20200312/cdaecd37/attachment.html>