On Mon, Dec 01, 2008, Nelson A. de Oliveira wrote:
> My intention is still wait for Lenny to be released, send a message
> saying "I will upload the new imagemagick package to unstable in X
> days, you need to do foo and bar and I will NMU your package in Y days
> for the transition" to the maintainers that still didn't upload a
> fixed package to experimental.

 Ah, so you wanted to prepare the full transition in experimental and
 then have coordinated uploads; that mostly works, but it's not easy:
 not only to motivate people to upload to experimental, but also to
 coordinate the uploads to unstable when you push the new imagemagick.

> From my point of view, keeping a transitional libmagick++9-dev and
> libmagick9-dev will only delay the problem for some time [see: Lenny
> gets released; we upload the new imagemagick to unstable (with the
> transitional packages) and Squeeze gets released with them; in Squeeze
> + 1 we remove the transitional packages.

 No, I think you can remove them as soon as all rbdeps are using the new
 packages.

>                                          I am sure that there will be
> packages still depending on libmagick++9-dev and libmagick9-dev at
> this time and I don't want to have this work 2 releases away]. As I
> said, my plan is to do the transition in Lenny + 1 (and without the
> need of transitional packages).

 Why?  and even would there be, what's the harm?

 Of course it's up to you, but I think you should consider these two
 points:
 - if you provide transitional packages, you can upload imagemagick to
   unstable immediately after the lenny release.
 - if you provide transitional packages, imagemagick will be able to
   migrate to squeeze in its new version faster then if you don't.
 - virtual packages break versionned dependencies and cause subtle
   breakage; for instance graphicsmagick-libmagick-dev-compat provides
   libmagick++-dev and libmagick-dev and satisfies any build-dep on
   these.  Also, consider packages which aim at being backportable
   without any sourceful changes (with alternate build-deps which work
   in the previous release)

> I may be wrong and the other maintainers (Luciano and Daniel) may
> disagree, but I don't want to think and work on the transitional
> packages for a problem that just hits Ubuntu now.

 Sure, it only hits Ubuntu right now; I think it's going to be
 unnecessary pain for Debian as well.

-- 
Loïc Minier



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to