[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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
No need to upload allegro4.2 just for this if you plan to drop it before
the freeze.


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,

Reply to: