Re: Allegro 4.4 transition
There were two off-list mails, because I accidentally answered to
Ansgars mail address. I will summarize them here.
On 05/03/12 11:51, Ansgar Burchardt wrote:
On 05/03/2012 11:14 AM, Tobias Hansen wrote:
the Allegro 4.4 and 5 packages are now ready to be reviewed by possible
sponsors, either from the queue [1] or the git repositories [2,3].
I don't have time to review them, but please don't upload them to
unstable before the release team said so. Uploading to experimental is
of course fine.
I will file a transition bug against release.debian.org for Allegro 4.4,
but Allegro 5 should be ok to be uploaded, because it's a whole new
library and there's no transition involved.
allegro4.2 needs a simultaneous upload to remove the liballegro-doc
package, because allegro4.4 creates this one as a transitional dummy
package.
No need to upload allegro4.2 just for this if you plan to drop it before
the freeze.
Ok.
This is the rest of the transition that needs to be done after
allegro4.4 is uploaded:
Did you try rebuilding the affected packages (replace build-dependencies
as required locally)?
Yes, they all compiled and worked fine.
Could compile without source change, but should still be updated:
(mostly build depend on "liballegro4.2-dev | liballegro-dev",
I think sbuild might not be happy with this (it only considers the first
alternative). Also liballegro4.2-dev is still around as long as
allegro4.2 is still in the archive.
I answered to this that it means that we need source uplaods for
eveything except maybe ballz. Ansgar suggested that liballegro4.4-dev
could provide liballegro4.2-dev. I think that's a very god idea, because
then we would presumably only need one source upload to fix the bug in
open-invaders.
Then the transition would go like this, right?
- Upload allegro4.4.
- Remove allegro4.2 and libalogg1.
- binNMUs for libdumb and guichan.
- binNMUs for the other reverse dependencies.
Best regards,
Tobias
Reply to: