[Pkg-owncloud-maintainers] Nextcloud desktop client packaging

[István Váradi]

Hi,

the patches for this new kind of packaging have been merged into the
official Nextcloud repository.

Istvan

On Sun, Mar 15, 2020 at 7:54 AM István Váradi <ivaradi at varadiistvan.hu>
wrote:

> 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/20200501/fba73ad2/attachment.html>