Older binary versions are accepted after a package is deleted in the same suite

Bug #66974 reported by Malcolm Cleaton
8
Affects Status Importance Assigned to Milestone
Launchpad itself
Triaged
High
Unassigned

Bug Description

Soyuz doesn't perform enough checks on the versions of uploaded binaries.

It will check that there isn't already a published binary newer than the candidate in the same distrorelease, including the correct handling for backports.

However, it will not check in prior distroreleases. So, if a package was in dapper, previously removed in edgy, and then a new source upload to edgy builds an older version of the same binary package, it will be accepted and published, when it shouldn't be.

This happened recently with the binary package ndiswrapper-utils, which is in edgy at version 1.1-5 (from the source package named "ndiswrapper-utils-1.1") but in dapper at version 1.8-0ubuntu2 (from a source package named "ndiswrapper-utils").

There was also some discussion of a stronger check, which would forbid publishing a version of a package which was lower than any version previously published, in that or any prior distrorelease, even if the previous version has been removed.

This is theoretically do-able in Soyuz, but could get complex; if a very high version number were accidentally uploaded and quickly deleted, and we wanted to work around the check in this case, we'd need to erase it entirely from history, or have a second "seriously, this is REALLY removed, kthxbye" status, alongside the existing removed status, to indicate that the check shouldn't apply. It sounds like this stronger check is not sufficiently required to complicate things so.

But, in the meantime, we do need to properly check against still-published higher version releases anywhere else in the distribution.

Changed in soyuz:
importance: Undecided → High
status: Unconfirmed → Confirmed
Revision history for this message
Malcolm Cleaton (malcolmcleaton) wrote :

We should also either try to refuse source package uploads which we can see will lead to a build which will be refused, or make sure we fix bugs 32261 and 32404, so that rejecting a build result doesn't have such sucky outcomes. Or maybe both.

Revision history for this message
Adam Conrad (adconrad) wrote :

You can't determine the versions of the binary packages from looking at a source package, as the versions don't always map 1:1, so trying to reject at the source stage is a waste of time and effort.

Take, for example, php-imap, with a source version of 5.1.2-1, which generates binary packages php5-imap version 5.1.2-1 and php4-imap version 4:5.1.2-1 (note the epoch). There's no way to test for that, as it's done in debian/rules.

tags: added: soyuz-upload
Revision history for this message
Tom Haddon (mthaddon) wrote :

This just required http://pastebin.ubuntu.com/535204/ to be run manually against the DB

tags: added: canonical-losa-lp
Revision history for this message
Robert Collins (lifeless) wrote :

@julian why the soyuz-upload tag? Needs to be at publish time, no?

summary: - Binary versions not checked correctly
+ Older binary versions are accepted after a package is deleted in the
+ same suite
Revision history for this message
William Grant (wgrant) wrote :

No, the archive DB state has to always be valid. And this has nothing whatsoever to do with publishing.

Revision history for this message
William Grant (wgrant) wrote :

Also, I'm not really sure that this bug is directlry related to the SQL in comment #3. This isn't about preventing binary filename conflicts.

I suspect that this bug is better solved outside LP. Something external could just as easily compare versions between series, alerting when a package goes backwards.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.