Package pruning can happen in wrong track

[cottsay]

It looks like (a2e2c2d) was created to verify that a package is still in the upstream repository, but the upstream branch isn't necessarily set the right upstream branch (or URL for that matter) for a given track at generation time.

Repro:

• Release a package for hydro
• Release the package for indigo
• Generate the package for hydro (doesn't matter what -i is)
• upstream branch is still tracking the upstream for the indigo track, so a possibly incorrect package list is generated while pruning

I found this while generating for ros_comm, where rosgraph_msgs (and maybe others) are present in H but not I.

A possible solution would be to set up separate upstream branches for each track, ie:

• upstream/hydro
• upstream/indigo

...which would mean that the release process for a single track would no longer "share" any branches with another track, something that could probably happen for more reasons than just this.

Another short-term workaround might be better in the mean time, but this is a pretty specific use-case, so I'm not terribly worried about lots of users hitting it.

Thoughts?

--scott

[wjwwood]

Another option is that since the track stores the last version released for each track, we could try to look at the upstream tags, e.g. upstream/0.1.2 rather than upstream for the checking.

[cottsay]

That would probably work for the majority of cases. If I'm not mistaken, however, it is POSSIBLE to configure two tracks to have different upstream URLs/branches but have the same version and still differ in contents.

I'd suppose that we could note this scenario in the documentation and require a version difference if the contents are different...

[wjwwood]

Yeah, that's an underlying assumption, that if the upstream version doesn't change neither does the content. This doesn't always hold in practice and early on it really didn't so that's why we import upstream every time even if we already have that version available in the upstream history.

[tfoote]

I've proposed to change the auto reimport behavior and require an override flag, as it's bad practice. And at least make the users aware of the bad practice in #258