Packaging git submodule as multi upstream tarballs?

[Daniel Gröber]

Hi Mentors,

I'm working on packaging prjtrellis[1] which has a git submodule that is
required for building. My plan is to use dpkg-source's multi upstream
tarball support to do this.

[1]: https://github.com/YosysHQ/prjtrellis

I'm wondering if a) this is a good idea and 2) how to get uscan to download
the precise commit referenced in the main package instead of the "latest"
version. Is this even possible?

I have a similar situation in my yosys package already (it has a
berkeley-abc submodule) but since berkeley-abc is just a seperate package I
just package the latest berkeley-abc commit and pray it doesn't diverge
from what upstream's release uses too much. This is less than ideal
obviously.

Any input would be appreciated,
--Daniel

[Paul Wise]

On Tue, 2023-06-13 at 16:48 +0200, Daniel Gröber wrote:

> I'm working on packaging prjtrellis[1] which has a git submodule that is
> required for building. My plan is to use dpkg-source's multi upstream
> tarball support to do this.

This appears to be the repo of the submodule:

https://github.com/YosysHQ/prjtrellis-db

I note Arch Linux uses a separate database package:

   $ grep database .github/archlinux/PKGBUILD
     # The database is provided in a separate package
     rmdir "$pkgdir"/usr/share/$_prj/database

> [1]: https://github.com/YosysHQ/prjtrellis

This repo contains embedded code copies, please follow this advice:

https://wiki.debian.org/EmbeddedCopies

--
bye,
pabs

https://wiki.debian.org/PaulWise

[Ryan Pavlik]

I'm not sure if uscan can do it, but for meshlab, as they don't tag the submodule when they release the main project, I have a script that updates the submodule commit using the github API. It's more clunky than I'd like, but I am not sure exactly how to fix this. It parses the version out of debian/changelog to find the main repo revision. https://salsa.debian.org/science-team/meshlab/-/blob/master/debian/get-orig-source.sh

Ryan

[Daniel Gröber]

Hi Ryan,

On Wed, Jun 21, 2023 at 03:07:24PM -0500, Ryan Pavlik wrote:
> I'm not sure if uscan can do it,

I did get it working but it's exceedingly cludgy. I have to use mode=git
for the second component since uscan can't just download master.tar.gz
AFACT (it's at a static location not linked from a page). I also have to
set the version to "ignore" instead of "same" as the generated git commit
based version is obviously not going to match the main project tag.

Further I have to disable the uupdate hook since 1) it would have to be
attached to the second component to work properly but 2) it gets passed the
generated git version which again doesn't match the main tarball so it
barfs as it can't find the orig.tar.

What a mess.

So I have this now:

version=4
opts=filenamemangle=s%(?:.*?)?v?(\d[\d.]*)\.tar\.gz%@PACKAGE@-$1.tar.gz%,\
https://github.com/YosysHQ/prjtrellis/tags \
(?:.*?/)?v?(\d[\d.]*)\.tar\.gz debian

opts=mode=git,\
component=database \
https://github.com/YosysHQ/prjtrellis-db.git \
HEAD ignore

> but for meshlab, as they don't tag the submodule when they release the
> main project, I have a script that updates the submodule commit using the
> github API. It's more clunky than I'd like, but I am not sure exactly how
> to fix this. It parses the version out of debian/changelog to find the
> main repo revision.
> https://salsa.debian.org/science-team/meshlab/-/blob/master/debian/get-orig-source.sh

I was looking for an API endpoint to get the submodule commit actually,
this way at least I don't have to do a temp clone just to get it. This is
super useful, thanks!

--Daniel