Branch pointers do not follow deletions, breaking ubuntu/devel and such

[Christian Ehrhardt ]

Hi,
at the current state the branches seem to be wrong.

Rmadison:
 libseccomp | 2.4.1-0ubuntu0.19.04.3 | disco-updates | source
 libseccomp | 2.4.1-0ubuntu0.19.10.3 | eoan | source
 libseccomp | 2.4.1-0ubuntu0.19.10.3 | focal | source

But we have:
commit b02a251b0be8f54e0333819d9a0b1d5d23df67df (tag: pkg/import/2.4.1-2, pkg/ubuntu/focal-proposed, pkg/ubuntu/focal-devel, pkg/ubuntu/devel)

This is just "wrong".

It is not that the right import would not exist, there is;
commit fd075d8c24413b995dae12b82f6a91581b5510bf (tag: pkg/import/2.4.1-0ubuntu0.19.10.3, pkg/ubuntu/focal, pkg/ubuntu/eoan-proposed, pkg/ubuntu/eoan-devel, pkg/ubuntu/eoan)

focal-devel, focal-proposed, and ubuntu/devel should point to the latter.

Could you please check what went wrong on the import to avoid having more broken repos in the future?

[Robie Basak (racb)]

Apparently 2.4.1-2 _was_ previously published in Ubuntu: https://launchpad.net/ubuntu/+source/libseccomp/+publishinghistory

The current importer algorithm is specified not to follow deletions.

Do you think it should? If so, we can turn this bug into "Branch pointers do not follow deletions" and then try to figure out what the semantics should be.

I think there are edge cases that make the specification of appropriate semantics difficult or impossible.

[Christian Ehrhardt  (paelzer)]

Hmm,
here is what I'd expect on a deletion:

1. keep the import in git
2. modify the deleted tag in a way to not collide on an equal import later could be -deleted or something like it
3. I'd expect the branch pointers to be reset to properly represent what a user is supposed to work on e.g. ubuntu/devel still is the right start and such

[Robie Basak (racb)]

Since the proposal is to delete or reset branch pointers rather than any change to the commit graph, this won't be hash-abi-break.

[Robie Basak (racb)]

> 2. modify the deleted tag in a way to not collide on an equal import later could be -deleted or something like it

This stop won't be necessary because Launchpad won't permit an import of the same version in the same distribution but with different contents. A subsequent upload would have to bump the version beyond what was used previously.

But this exposes one of those awkward edges of "just winding the branch pointer back". A developer using git-ubuntu won't know that the deletion happened, and so won't know that a simple version bump won't work. Admittedly this happens without git-ubuntu though.

That's why I'm half inclined to think that the current situation is better. The developer does need to know that the deleted publication did happen, and does need to make an informed decision on how to handle that - preferably *before* starting work. So maybe this is something that we could better detect communicate in the client, rather than changing the git-ubuntu repository "format".

[Bryce Harrington (bryce)]

Communicating the situation in the client would indeed save some chunk of time. I ran into this for an nmap sru recently, and while I indeed did the steps described in the last paragraph of comment #4, I hadn't run into this corner case before, and it definitely took some head scratching time to figure out.

Also, it didn't occur to me the MP would also need targeted to jammy rather than jammy-devel as usual, so the diff ended up showing a ghost conflict:

https://code.launchpad.net/~bryce/ubuntu/+source/nmap/+git/nmap/+merge/437077

It would be ideal if we could rely on *-devel always pointing to the correct tip, but if we can't then having a (mechanical) way to detect when it doesn't would be the next best thing.

[Robie Basak (racb)]

> That's why I'm half inclined to think that the current situation is better.

See also bug 2028288. The solution for that bug may require us to force push the branch pointers following deletions. If we do that then we'll be choosing the other side of the coin: higher version strings "already burned" wouldn't be well understood by developers.