tis 2025-08-19 klockan 15:33 +0100 skrev Ian Jackson:
> This seems to be best discussed as part of #1079434,
> so moving the discussion there:
>
> Simon Josefsson writes ("Bug#1111548: tag2upload service makes .origs
> with un-defused gitattributes"):
> > If you make dgit not respect .gitattributes,
> ...
>
> Firstly, dgit has suppressed .gitiattributes since January 2017. Oh! My mistake. The reason things work for libidn (and other projects that use .gitattributes export-subst for .tarball-version-git to set the ./configure version number) is that I import a 'git-archive' tarball (done WITH support for .gitattributes) into Salsa, and that was used to upload into dgit. I realize now that if I would change and use a git- to-git mechanism pulling in upstream git content into Salsa, things will break, since then the .gitattributes conversion is lost, and I would need a debian/patches/ workaround to fix things. I'm happy with this setup (it gives me PGP authentication of the upstream git-archive tarballs), and definitely agree you should not respect .gitattributes in dgit/tag2upload because that path leads to madness. I think this complicate moving towards fully git-based workflows where upstream git is pulled into dgit and then built for Debian. Many upstream rely on export-subst-like mechanism to set the version number, and this is a nice git feature, and I don't think we are in a position to say they are wrong to use it. Re-reading the original report for #1111548 make me believe that the proper solution is to document the following somewhere: If upstream uses .gitattributes to achieve something magical, you need to replicate all necessary magic via debian/rules and/or via debian/patches/. You cannot rely on .gitattributes doing the right thing in the Debian dgit/tag2upload workflow, in fact you can and should only rely on it doing nothing. /Simon
signature.asc
Description: This is a digitally signed message part
