Bug#792096: borg packaging
Hello everyone,
I was surprised to see the reaction my comments generated and like
Gianfranco, I also want to ask Marc to consider rethinking his decision.
I do not think you are spoiling the fun or that insisting on
oldfashioned keeping is a bad thing. I apologize that my choice of
words made you feel that way - I am not a native english speaker either,
so it may have sounded different than I intended.
I chose github as a mirror because I have upload rights there, that's
the only reason. I would also prefer to work on *.debian.org and I will
do so once I have permission. I just thought hosting git repo online
somewhere makes looking at it easier than sending stuff by mail, and
using github seemed like the easier choice than hosting and maintaining
a git browser myself. Since git clones contain the entire history,
switching mirrors shouldn't be complicated once upload permission is
granted.
I chose the "ignore upstream tarball/use git tag" method also just
because it was simpler. Had I imported the release tarball, I would
have had to maintain the list of files that are auto-generated (a simple
*.c won't do, for example _chunker.c is handwritten), and add rules to
remove them from the build dir or change their timestamp so that they
get refreshed at build-time. Not having them in the first place made
that unnecessary. That's the reason why upstream git tag seemed easier
to create a working example implementation of the "regenerate files" idea.
The git tag is gpg-signed with the same key as the tar.gz release, so I
don't really see the difference in authenticity, please elaborate why
.tar.gz would be superior for validation of borgbackup. From what I
understand, an end-user will trust whatever checksum the Maintainer puts
into .changes and signs with maintainer key, so this is just an issue of
what the maintainer trusts. Or am I getting this wrong?
- Danny
Reply to: