Ian Jackson <[email protected]> writes: > [dgit distro=debian split --quilt=baredebian+tarball]
Oh! That is not what I intended. > The information in the tag doesn't say, but I am almost certain that > Simon didn't specify baredebian+tarball explicitly. I can confirm this: I just ran 'git-debpush'. I expected/wanted it to fail because I wanted to use 'git-debpush --quilt=baredebian+git' and wanted to find out how git-debpush fails when I do not specify it. Alas git-debpush created a tag and pushed it. So I did a manual upload to get that version into the archive. > The previous upload was done with dgit, and > --quilt=baredebian+tarball. > https://browse.dgit.debian.org/cppi.git/tag/?h=archive/debian/1.18-3 Tag2upload wasn't a thing then. Since the last upload, I added a upstream branch and the corresponding upstream tag: https://salsa.debian.org/debian/cppi/-/commits/upstream?ref_type=heads This is because I wanted to switch to tag2upload for this package. That branch didn't exist before. I don't feel strongly about using baredebian for this package, but I want to gain experience with difference packaging strategies to see how they play out. > So I think git-debpush just reused that quilt mode. Do qit-debpush generally look at the PREVIOUS tag to make any decisions right now? As a user I really prefer if it didn't, but I don't know what the concerns are. I thought git-debpush was stateless wrt earlier upload history of the git repository, if that isn't the case I'll have to reclibrate my intuition. > For an existing upstream version, the upload could theoretically have > succeeded if we could have told the service "there is an orig in the > archive, you mmust use that". I'm not sure our tag format has a way > of requesting this, but the service implementation doesn't: it > tries to obtain origs iff there is an upstream commitid in the tag. I don't think one should have to specify that: is there a reason tag2upload should not ALWAYS use the tarball from the archive, if one exists, instead of synthesizing one? This upload was not a new upstream version, just a incremental update. Anything but the archive tarballs will be rejected, I suppose. > For a new upstream version, this quilt mode cannot be supported, > because it would involve conveying a tarball from the user's system to > the service. (#1106071 is relevant, but I doubt we would want > git-debpush to *generate* pristine-tar data.) > > Anyway, at the very least git-debpush ought to have stopped rather > than asking the service to do something nonsensical. Yes, erroring out is what I expected. I still have to test if 'git-debpush --quilt=baredebian+git' actually works for this package. Do you have any guess? Hopefully I can find some nit in the latest upload and test it. /Simon
signature.asc
Description: PGP signature
