Superseded binaries shown as FULLYBUILT_PENDING

[William Grant]

I just uploaded a new xserver-xorg-input-synaptics source to my PPA. It built, producing the xserver-xorg-input-synaptics binary. This binary was previously built by xfree86-driver-synaptics, which remains in the same series in that archive, with its binaries superseded. That's all fine.

However, Archive:+index and getBuildSummariesForSourceIds are of the opinion that the old builds for xfree86-driver-synaptics are FULLYBUILT_PENDING. There are no Pending binary publications in this archive.

[Michael Nelson (michael.nelson)]

Hi William,

I couldn't find a cause in the ui code, so Celso had a look and thought that this was actually a result of bug 381756. Did you resurrect any deleted sources for that package?

I'll mark it as a dupe, but if you're certain that this is not the case, un-mark it and I'll take another look.

[William Grant (wgrant)]

No - neither of those sources were ever deleted (as you can see on https://edge.launchpad.net/~wgrant/+archive/ppa).

You could probably reproduce on dogfood by uploading first xfree86-driver-synaptics 1.1.0-0ppa2, letting it build, and then uploading xserver-xorg-input-synaptics 1.1.1~git20090510-1ubuntu1~wgrant2.

[Celso Providelo (cprov)]

The repository state is fine, xserver-xorg-input-synaptics 1.1.1~git20090510-1ubuntu1~wgrant2 binaries superseded the xfree86-driver-synaptics 1.1.0-0ppa2 ones, so the later source is *cruft* (published but not needed anymore since none of its binaries are published).

This is a useful piece of information for archive administrators, we currently run into troubles once a while calculating this for the primary archive; however I'm not sure it is needed in the PPA domain.

I think we can do either of:

 1. Ignore this condition and make the source FULLYBUILT;
 2. Introduce a new build status FULLYBUILT_CRUFT and present it in the UI accordingly.

(my vote is 2)

What would you prefer ?

[Julian Edwards (julian-edwards)]

It needs to be something like FULLYBUILT_SUPERSEDED, I don't like the use of
"cruft" here.

[William Grant (wgrant)]

I think #2 is good - it should probably be made obvious that those binaries aren't actually the ones in the archive.

[Michael Nelson (michael.nelson)]

OK, after chatting with wgrant, I think I understand this situation a bit better now. To summarise this for a non/new Debian developer (please correct me if I'm wrong):

1. Upload MySourcePackage 0.1.0
2. Upload PotentiallyRelatedOrOutdatedPackage 0.3.1

So PotentiallyRelatedOrOutdatedPackage is Published.

Now, if MySourcePackage produces the binary 'some_tool' (v. 0.3.1) and PotentiallyRelatedOrOutdatedPackage 0.3.1 also produces the 'some_tool' binary, but v. 0.3.0, then we have the situation where the SPPH is fullybuilt, but the binary will never be published.

BUT, isn't it also possible that PotentiallyRelatedOrOutdatedPackage might produce 20 binaries, only one of which is superseded? In which case, does it really make sense to describe this SPPH in the UI as FULLYBUILT_SUPERSEDED, as some of its binaries (perhaps all but one) are published. Or perhaps this situation is possible but not likely?

Secondly, we would need to issue a second query for every SPPH that has unpublished records. Currently if the SPPH is FULLYBUILT, we request all the unpublished builds for that SPPH (expensive query). To implement option (2), for every SPPH that has unpublished builds, we'd need to issue a second query to see if there is already a later BPPH for this binary (although that query should be cheap).

Third, we'd need a new icon to represent this state right? (At least, I can't see anything slightly relevant at https://edge.launchpad.net/+graphics .) I'll ping beuno today.

[William Grant (wgrant)]

That's not quite right. I think some_tool 0.3.0 will fail to upload in the situation you gave, but I couldn't be sure.

The situation this bug is about goes something like this:

1. Upload SP1 1.0.
2. SP1 1.0 builds, producing BP 1.0.
3. Publisher runs. The archive now contains SP 1.0, and BP 1.0.
3. Upload SP2 2.0
4. SP2 2.0 builds, producing BP 2.0.
5. Publisher runs. The archive now contains SP2 2.0, BP 2.0, and SP1 1.0, but not SP1 1.0's binary (BP 1.0).

That is, both sources are published, but one has missing binaries. The one with missing binaries currently shows up as FULLYBUILT_PENDING - it should be FULLYBUILT_SUPERSEDED.

[Michael Nelson (michael.nelson)]

Ah, so I misinterpreted when Celso said "so the later source is *cruft*". OK. I'm guessing then that Celso meant "so the older source is *cruft*" or similar.

[Michael Nelson (michael.nelson)]

So after chatting with Celso about this, so that we can fix this now without waiting for a new icon, we'll implement (1) 'Ignore this condition and make the source FULLYBUILT' for the moment. When we have an icon to represent cruft, we can add the new status and display it in the UI.

[Diogo Matsubara (matsubara)]

Fixed in devel r8906.