[Pkg-owncloud-maintainers] Nextcloud desktop client packaging

[István Váradi]

Hi again,

I have created some example branches in my fork of the desktop client:
https://github.com/ivaradi/nextcloud.client

One branch is called "debian/base" and it contains only the "debian"
directory. It could be used to put the common modifications here which
could then be merged into the distribution and release-specific branches.
Currently it contains a copy of the "debian" directory from the salsa
repository, with two modifications: the upstream branch is made "master" in
gbp.conf and I have added the transitional packages for compatibility with
the current package names in the PPA.

The other branch is "debian/ubuntu/eoan/master" which is forked from the
master branch and the contents of "debian/base" are merged into it. It is
supposed to be the branch for the Eoan distribution builds from the master
branch, i.e. from the cutting-edge version. While the name is different
(and I am still not sure about the naming, so it is not final) from hefee's
suggestion, the idea is basically the same. However, I see no point in
creating the "upstream/..." branch hierarchy, as the "normal" branches can
be used as upstream, but I may be wrong about that.

With this approach I could implement the automatic build for the PPA, and I
believe it is also compatible with the usual Debian way of packaging.

Could someone, please, review these branches, and let me know any
suggestions, ideas, etc? I am also interested in any suggestions for the
my questions related to the common changelog and the handling of the source
code diverging from a basic .orig.tar.gz for a certain version.

Istvan

On Thu, Mar 12, 2020 at 6:57 AM István Váradi <ivaradi at varadiistvan.hu>
wrote:

> 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/20200315/2e0814e5/attachment.html>