Dear mentors,

I am working on packaging the Caddy web server. Caddys github repo[1] only includes the platform-agnostic files (mostly .go source files) needed for building and testing.
distro-specific files such as systemd unit files, bashcompletion, pre/post(un)install scripts etc have been moved to a seperate "dist" repo[2].

I am wondering what would be a good way to include these in the package. I have two options in mind:

1. uscans "group" feature

One way would be to specify both repos in debian/watch. I have tried this and it works fine regarding the packaging workflow.

The problem that I see here is that it results in an overly complicated package version number (such as x.y.z+~0.0~git20210811.abcdefg-1) that would cause confusion for debian users and has no practical use for neither users nor maintainers:

the dist-repo has no releases or tags, so uscan would usually download HEAD. A situation were one would want to package a specific commit is very unlikely: the different repos are not builddeps of each other and could not mismatch or "break" each other.
also, if some changes were not suitable for debian IMO that should be fixed with a debian patch on top of HEAD or discussed with upstream, not by rolling back to an earlier commit.

2. include in debian/missing-sources

another option would be to add the dist repo to missing sources and use postclone or post-import command of gbp or a shellscript for manual execution to easily keep it up-to-date when packaging a new release.

in the unlikely case there is bugs discovered in the dist repo, bugfixes would be packaged in an debian revision (with no extra version string for dist)

this seems like the reasonable option to me, only I fear that this is not the "correct" way or even misuse of missing-sources: after all the files are not actually missing sources of a packaged binary, but simply additional files that belong with caddy.

I would be interested what you think about this, or if you would maybe even suggest another solution?

Peymaneh

[1] https://github.com/caddyserver/caddy
[2] https://github.com/caddyserver/dist

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Peymaneh,

the dist-repo has no releases or tags, so uscan would usually download HEAD.

Perhaps you could ask upstream for tags matching their releases? It
seems they're already updating version numbers within the "dist" repo
for every release anyway.

A situation were one would want to package a specific commit is very unlikely: the different repos are not builddeps of each other and could not mismatch or "break" each other.

Surely they could mismatch. For example, "dist" contains shell
completion scripts. Those would need to be kept in sync with the
application's actual interface, which could presumably change between
versions.

Regards,
Robin

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, Aug 11, 2021 at 1:54 PM Peymaneh Nejad wrote:

I am working on packaging the Caddy web server. Caddys github repo[1] only includes the platform-agnostic files (mostly .go source files) needed for building and testing.
distro-specific files such as systemd unit files, bashcompletion, pre/post(un)install scripts etc have been moved to a seperate "dist" repo[2].

I am wondering what would be a good way to include these in the package.

Three options that I can think of:

Convince upstream to include the dist files in the main repo again.

Use dpkg-source v3 multiple upstream (MUT) tarballs, which uscan
supports, search for component/MUT in the manual page.

Create two source packages to mirror what upstream has done.

--
bye,
pabs

https://wiki.debian.org/PaulWise

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Good day Everybody..

Im prepaing a system to build /rebuild packages with sbuild.

I used this to setup :
https://wiki.debian.org/sbuild
( its missing a few packages like : dh-python dh-make )

It works but.. (which is why i sending this email).

Per example, im updating Talloc to 2.3.3
Running : sbuild -d bullseye works fine.
All my amd64 packages are created, no errors, perfect.. Just..

When I run the builder with : sbuild -d bullseye --host=armhf
So i can cross-build the armhf packages.

Im hitting this error and i cant find why or find any solution.

Setting up python3.9-minimal:armhf (3.9.2-1) ... /var/lib/dpkg/info/python3.9-minimal.postinst: 51: /usr/bin/python3.9: Exec format error
dpkg: error processing package python3.9-minimal:armhf (--configure):
installed python3.9-minimal:armhf package post-installation script
subprocess returned error exit status 126
Setting up liblocale-gettext-perl (1.07-4+b1) ...

What am i missing? Anyone? Please? Im stuck..
Or should i report this as bug?
I dont know/cant find if this is a config thingy or bug thingy.. ;-)

Best regards,

Louis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)