Email::MIME and merge of ::Modifier and ::Creator

[Jonathan Yu]

Hi all:

So upstream has decided to merge Email::MIME::Modifier and
Email::MIME::Creator into Email::MIME (good catch gregor!). Note that
the current available versions of those packages upstream don't do
anything (the versions in Debian look like they're the last ones that
still work as they should).

See these PODs:
http://search.cpan.org/~rjbs/Email-MIME-1.901/lib/Email/MIME/Modifier.pm
http://search.cpan.org/~rjbs/Email-MIME-1.901/lib/Email/MIME/Creator.pm

where:
Email::MIME::Modifier - obsolete do-nothing library
Email::MIME::Creator - obsolete do-nothing library

So, I propose these modules for removal from sid. At the same time,
I'll set up the appropriate Conflicts/Replaces in libemail-mime-perl,
since it now provides those modules. There are a few rdepends for
these packages, so I think I should just add them to Provides in
libemail-mime-perl as well:

libemail-mime-creator-perl
Reverse Depends:
  libemail-mime-createhtml-perl
  libcatalyst-modules-perl
  bugzilla3
  libemail-mime-createhtml-perl
  libcatalyst-modules-perl
  libjifty-perl

libemail-mime-modifier-perl
Reverse Depends:
  libemail-mime-creator-perl
  bugzilla3
  bugzilla3
  libhttp-request-params-perl
  libemail-mime-creator-perl
  libjifty-perl

Thoughts from the team?

>From a cursory glance we can fix many of these (I'll take a closer
look later on) because they're group-maintained modules. However,
bugzilla3 lies outside the group I think.

Cheers,

Jonathan


--
To UNSUBSCRIBE, email to debian-perl-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[gregor herrmann-3]

On Sat, 07 Nov 2009 10:53:41 -0500, Jonathan Yu wrote:

> So, I propose these modules for removal from sid. At the same time,
> I'll set up the appropriate Conflicts/Replaces in libemail-mime-perl,
> since it now provides those modules.

First the Conflicts/Replaces/Provides, then the removal.

> There are a few rdepends for
> these packages, so I think I should just add them to Provides in
> libemail-mime-perl as well:

Ehm, no, we need the Provides so that those other packages can still
depend on something, we don't start to provide bugzilla magically :)
 
Cheers,
gregor
--
 .''`.   http://info.comodo.priv.at/ -- GPG Key IDs: 0x00F3CFE4, 0x8649AA06
 : :' :  Debian GNU/Linux user, admin, & developer - http://www.debian.org/
 `. `'   Member of VIBE!AT, SPI Inc., fellow of FSFE | http://got.to/quote/
   `-    NP: Rod Steward: I Don't Want To Talk About It

[Jonathan Yu]

gregor:

On Sat, Nov 7, 2009 at 12:19 PM, gregor herrmann <gregoa@...> wrote:

> On Sat, 07 Nov 2009 10:53:41 -0500, Jonathan Yu wrote:
>
>> So, I propose these modules for removal from sid. At the same time,
>> I'll set up the appropriate Conflicts/Replaces in libemail-mime-perl,
>> since it now provides those modules.
>
> First the Conflicts/Replaces/Provides, then the removal.
>
>> There are a few rdepends for
>> these packages, so I think I should just add them to Provides in
>> libemail-mime-perl as well:
>
> Ehm, no, we need the Provides so that those other packages can still
> depend on something, we don't start to provide bugzilla magically :)

Of course, what I meant is that under the new scheme:

libemail-mime-perl provides:
+ libemail-mime-creator-perl
+ libemail-mime-modifier-perl

And at the same time, the reverse dependencies under our control will
be repaired to point to libemal-mime-perl (rather than the things
which are Provided by libemail-mime-perl):

Instead of these dependencies requiring libemail-mime-creator-perl:
 libemail-mime-createhtml-perl
 libcatalyst-modules-perl
 bugzilla3
 libemail-mime-createhtml-perl
 libcatalyst-modules-perl
 libjifty-perl

The ones under our control, at least, will depend on libemail-mime-perl.

Instead of these dependencies requiring libemail-mime-modifier-perl:
 libemail-mime-creator-perl
 bugzilla3
 bugzilla3
 libhttp-request-params-perl
 libemail-mime-creator-perl
 libjifty-perl

The ones under our control, at least, will depend on libemail-mime-perl.

So for the latter two groups of modules, I'm just suggesting they
require the actual package directly (rather than the one Provided by
libemail-mime-perl)

>
> Cheers,
> gregor
> --
>  .''`.   http://info.comodo.priv.at/ -- GPG Key IDs: 0x00F3CFE4, 0x8649AA06
>  : :' :  Debian GNU/Linux user, admin, & developer - http://www.debian.org/
>  `. `'   Member of VIBE!AT, SPI Inc., fellow of FSFE | http://got.to/quote/
>   `-    NP: Rod Steward: I Don't Want To Talk About It
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iEYEARECAAYFAkr1rCEACgkQOzKYnQDzz+SiEACgz2ECg689AQTbqtuyiYKiQcBA
> DRgAn2yyN5CVgNHmDH4QtMZxUBjs816F
> =mMUI
> -----END PGP SIGNATURE-----
>
>

--
To UNSUBSCRIBE, email to debian-perl-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Jonas Smedegaard]

On Sat, Nov 07, 2009 at 12:35:34PM -0500, Jonathan Yu wrote:
>So for the latter two groups of modules, I'm just suggesting they
>require the actual package directly (rather than the one Provided by
>libemail-mime-perl)

Please include fallback for the old package names too, to ease
backporting, like this:

Depends: libemail-mime-perl (>= 1.863) | libemail-mime-creator-perl


Replace version number with the actual package where things got merged.
Please note how the Debian part of the version number is deliberately
left out.  That was also to ease backporting.  If the actual merge (for
some odd reason) did not happen at an upstream release, then include the
Debian part but in a backports-friendly way like this: 1.863-5~

When the functionality is provided by the main package even in
oldstable, the fallback can be dropped.


Kind regards,

  - Jonas

--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: [phone]  Website: http://dr.jones.dk/

  [x] quote me freely  [ ] ask before reusing  [ ] keep private

[Jonathan Yu]

Hi Jonas,

On Sat, Nov 7, 2009 at 1:24 PM, Jonas Smedegaard <dr@...> wrote:

> On Sat, Nov 07, 2009 at 12:35:34PM -0500, Jonathan Yu wrote:
>>
>> So for the latter two groups of modules, I'm just suggesting they
>> require the actual package directly (rather than the one Provided by
>> libemail-mime-perl)
>
> Please include fallback for the old package names too, to ease backporting,
> like this:
>
> Depends: libemail-mime-perl (>= 1.863) | libemail-mime-creator-perl
>
>
> Replace version number with the actual package where things got merged.
> Please note how the Debian part of the version number is deliberately left
> out.  That was also to ease backporting.  If the actual merge (for some odd
> reason) did not happen at an upstream release, then include the Debian part
> but in a backports-friendly way like this: 1.863-5~
>
> When the functionality is provided by the main package even in oldstable,
> the fallback can be dropped.

That's a really good point, I didn't think of that. Yes, that
definitely sounds like something we should do (where we have control);
I'll also suggest it in any wishlist bugs I file asking maintainers to
switch over.

If we go with this scheme, does this mean we can still drop the
Provides: eventually?


--
To UNSUBSCRIBE, email to debian-perl-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Niko Tyni-3]

On Sat, Nov 07, 2009 at 10:53:41AM -0500, Jonathan Yu wrote:

> Email::MIME::Modifier - obsolete do-nothing library
> Email::MIME::Creator - obsolete do-nothing library
>
> So, I propose these modules for removal from sid. At the same time,
> I'll set up the appropriate Conflicts/Replaces in libemail-mime-perl,
> since it now provides those modules. There are a few rdepends for
> these packages, so I think I should just add them to Provides in
> libemail-mime-perl as well:

Please note that at least
 libjifty-perl
 libcatalyst-modules-perl
 libhttp-request-params-perl
 bugzilla3
have versioned dependencies on either libemail-mime-creator-perl or
libemail-mime-modifier-perl, and those won't be satisfied by the
Provides: entries. (See policy 7.5)

Changing the dependencies to something like
 libemail-mime-perl (>= xxx) | libemail-mime-creator-perl (>= yyy)
should be enough, but this needs to be done before the removal happens
to avoid uninstallability problems.

Another concern I had was about an upgrade path for installations
with libemail-mime-creator-perl or libemail-mime-modifier-perl but no
libemail-mime-perl - those could have been left with the obsolete
module versions.  However, that doesn't seem to be a problem because
they depend on libemail-mime-perl in both lenny and sid.
--
Niko Tyni   ntyni@...


--
To UNSUBSCRIBE, email to debian-perl-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Jonas Smedegaard]

On Sat, Nov 07, 2009 at 01:47:48PM -0500, Jonathan Yu wrote:

>Hi Jonas,
>
>On Sat, Nov 7, 2009 at 1:24 PM, Jonas Smedegaard <dr@...> wrote:
>> On Sat, Nov 07, 2009 at 12:35:34PM -0500, Jonathan Yu wrote:
>>>
>>> So for the latter two groups of modules, I'm just suggesting they
>>> require the actual package directly (rather than the one Provided by
>>> libemail-mime-perl)
>>
>> Please include fallback for the old package names too, to ease
>> backporting, like this:
>>
>> Depends: libemail-mime-perl (>= 1.863) | libemail-mime-creator-perl
>>
>>
>> Replace version number with the actual package where things got
>> merged. Please note how the Debian part of the version number is
>> deliberately left out.  That was also to ease backporting.  If the
>> actual merge (for some odd reason) did not happen at an upstream
>> release, then include the Debian part but in a backports-friendly way
>> like this: 1.863-5~
>>
>> When the functionality is provided by the main package even in
>> oldstable, the fallback can be dropped.
>
>That's a really good point, I didn't think of that. Yes, that
>definitely sounds like something we should do (where we have control);
>I'll also suggest it in any wishlist bugs I file asking maintainers to
>switch over.
>
>If we go with this scheme, does this mean we can still drop the
>Provides: eventually?

Oh, yes, I totally forgot the underlying reason for this: Yes, the whole
Provides: can be dropped when no packages in unstable, testing or stable
depends only on the old names (which ideally means at the same time as
the fallbacks).


  - Jonas

--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: [phone]  Website: http://dr.jones.dk/

  [x] quote me freely  [ ] ask before reusing  [ ] keep private

[Jonas Smedegaard]

On Sat, Nov 07, 2009 at 10:25:03PM +0200, Niko Tyni wrote:

>On Sat, Nov 07, 2009 at 10:53:41AM -0500, Jonathan Yu wrote:
>
>> Email::MIME::Modifier - obsolete do-nothing library
>> Email::MIME::Creator - obsolete do-nothing library
>>
>> So, I propose these modules for removal from sid. At the same time,
>> I'll set up the appropriate Conflicts/Replaces in libemail-mime-perl,
>> since it now provides those modules. There are a few rdepends for
>> these packages, so I think I should just add them to Provides in
>> libemail-mime-perl as well:
>
>Please note that at least
> libjifty-perl
> libcatalyst-modules-perl
> libhttp-request-params-perl
> bugzilla3
>have versioned dependencies on either libemail-mime-creator-perl or
>libemail-mime-modifier-perl, and those won't be satisfied by the
>Provides: entries. (See policy 7.5)
>
>Changing the dependencies to something like
> libemail-mime-perl (>= xxx) | libemail-mime-creator-perl (>= yyy)
>should be enough, but this needs to be done before the removal happens
>to avoid uninstallability problems.
>
>Another concern I had was about an upgrade path for installations
>with libemail-mime-creator-perl or libemail-mime-modifier-perl but no
>libemail-mime-perl - those could have been left with the obsolete
>module versions.  However, that doesn't seem to be a problem because
>they depend on libemail-mime-perl in both lenny and sid.

Why make fallback to libemail-mime-creator-perl (>= yyy) versioned?

I see no need for that.


  - Jonas

--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: [phone]  Website: http://dr.jones.dk/

  [x] quote me freely  [ ] ask before reusing  [ ] keep private

[Niko Tyni-3]

On Sat, Nov 07, 2009 at 10:04:57PM +0100, Jonas Smedegaard wrote:
> On Sat, Nov 07, 2009 at 10:25:03PM +0200, Niko Tyni wrote:

>> Please note that at least
>> libjifty-perl
>> libcatalyst-modules-perl
>> libhttp-request-params-perl
>> bugzilla3
>> have versioned dependencies on either libemail-mime-creator-perl or
>> libemail-mime-modifier-perl, and those won't be satisfied by the
>> Provides: entries. (See policy 7.5)
>>
>> Changing the dependencies to something like
>> libemail-mime-perl (>= xxx) | libemail-mime-creator-perl (>= yyy)
>> should be enough, but this needs to be done before the removal happens
>> to avoid uninstallability problems.

> Why make fallback to libemail-mime-creator-perl (>= yyy) versioned?
>
> I see no need for that.

Well, I was talking about current versioned dependencies. I assume
the versions are mentioned for a reason. As an example:

 Package: bugzilla3
 Version: 3.2.4.0-3+nmu1
 Depends: [...], libemail-mime-modifier-perl (>= 1.442-2), [...]

would need to be changed to

 Depends: [...], libemail-mime-perl (>= 1.900) | libemail-mime-modifier-perl (>= 1.442-2), [...]

Sorry if I'm missing something.
--
Niko Tyni   ntyni@...


--
To UNSUBSCRIBE, email to debian-perl-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Jonas Smedegaard]

On Sat, Nov 07, 2009 at 11:19:20PM +0200, Niko Tyni wrote:

>On Sat, Nov 07, 2009 at 10:04:57PM +0100, Jonas Smedegaard wrote:
>> On Sat, Nov 07, 2009 at 10:25:03PM +0200, Niko Tyni wrote:
>
>>> Please note that at least
>>> libjifty-perl
>>> libcatalyst-modules-perl
>>> libhttp-request-params-perl
>>> bugzilla3
>>> have versioned dependencies on either libemail-mime-creator-perl or
>>> libemail-mime-modifier-perl, and those won't be satisfied by the
>>> Provides: entries. (See policy 7.5)
>>>
>>> Changing the dependencies to something like
>>> libemail-mime-perl (>= xxx) | libemail-mime-creator-perl (>= yyy)
>>> should be enough, but this needs to be done before the removal happens
>>> to avoid uninstallability problems.
>
>> Why make fallback to libemail-mime-creator-perl (>= yyy) versioned?
>>
>> I see no need for that.
>
>Well, I was talking about current versioned dependencies. I assume
>the versions are mentioned for a reason. As an example:
>
> Package: bugzilla3
> Version: 3.2.4.0-3+nmu1
> Depends: [...], libemail-mime-modifier-perl (>= 1.442-2), [...]
>
>would need to be changed to
>
> Depends: [...], libemail-mime-perl (>= 1.900) | libemail-mime-modifier-perl (>= 1.442-2), [...]
>
>Sorry if I'm missing something.

Oh, sorry: I saw it wrongly as a suggestion on "no _newer_ versions than
this one".

Your previous mail makes perfect sense to me now (I just had a shower,
that might have been what freshened up my vision :-P ).


  - Jonas

--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: [phone]  Website: http://dr.jones.dk/

  [x] quote me freely  [ ] ask before reusing  [ ] keep private

[gregor herrmann-3]

On Sat, 07 Nov 2009 22:25:03 +0200, Niko Tyni wrote:

> Please note that at least
>  libjifty-perl
>  libcatalyst-modules-perl
>  libhttp-request-params-perl
>  bugzilla3
> have versioned dependencies on either libemail-mime-creator-perl or
> libemail-mime-modifier-perl, and those won't be satisfied by the
> Provides: entries. (See policy 7.5)

Ack, but by transitional dummy packages which should also be added
IMO.
 
Cheers,
gregor
--
 .''`.   http://info.comodo.priv.at/ -- GPG Key IDs: 0x00F3CFE4, 0x8649AA06
 : :' :  Debian GNU/Linux user, admin, & developer - http://www.debian.org/
 `. `'   Member of VIBE!AT, SPI Inc., fellow of FSFE | http://got.to/quote/
   `-    NP: Queen: The Millionaire Waltz