[Piuparts-devel] piuparts testing for wheezy-next and squeeze2wheezy-next

[Adam D. Barratt]

On 2013-05-16 10:40, Andreas Beckmann wrote:
> My question for the RT: is wheezy-proposed-updates a superset 
> including
> the packages from wheezy-updates and wheezy/updates? (Except perhaps 
> for
> a short timespan a security update needs before shows up in s-p-u).
> So I would only need to merge the Packages files from wheezy and
> wheezy-proposed updates to get the full set of target packages 
> (keeping
> only the newest version). Or should I better merge wheezy +
> wheezy/updates + wheezy-updates + wheezy-proposed-updates?

Packages in $DIST-updates will have been in $DIST-proposed-updates at 
some point, but may not be there now - for example, if a point release 
has occurred since the package was added to -udpates; in that case, the 
version in $DIST will be >= $DIST-updates.

Unfortunately the time between a package being released via security 
and being accepted in to -proposed-updates can be quite lengthy. We 
won't flag the security package for acceptance until all of the builds 
are available; otherwise the buildds will rebuild it in p-u and the two 
archives will end up with different packages with the same version 
number, changelog etc. By way of an illustration, the mysql-5.1 packages 
from DSA2496-1 are still in squeeze-p-u-NEW, because it FTBFS on ia64.

At the time of the final etch point release, there were still packages 
from security sitting in opu-NEW for the above reason; we finally 
accepted them in to opu as they were never going to be tried again on 
security and it meant we got build logs (iirc all but one of them still 
failed to build)

Regards,

Adam