-=| Martín Ferrari, 15.05.2014 02:40:12 +0200 |=-
> [removing ftp master from cc]
>
> On 14/05/14 22:59, Damyan Ivanov wrote:
>
> > So the plan is to package all these 32 upstream projects as separate
> > source packages with their own life. For Jessie
> > libcatalyst-modules-perl will become a meta-package depending on the
> > separate packages (recommending the deprecated ones). It may go away
> > after the Jessie release.
>
> It's probably a bit too late to say this (sorry, I came late to the
> discussion), but probably it would be a better idea to make that
> recommends a depends (or at least a prominent notice in Debian.NEWS), as
> many people who uses this maybe has already disabled auto-installation
> of recommends, and surprise breakage would happen.
Good point. And it is not too late, as libcatalyst-modules-perl is not
uploaded yet (a couple of split packages pending upload). Another
reason to keep the hard dependency is that several packages depend on
libcatalyst-modules-perl. That needs to be changed to a direct
(non-meta-)package dependency, but in the mean time we don't want to
break them.
> I would keep it a depends until Jessie, and then downgrade to
> recommends, or remove the metapackage.
What would be preferable to people actually using Catalyst (that
excludes me)? Is such a meta-package of any use? Perhaps its function
can be accomplished via libcatalyst-perl's Recommends/Suggests (e.g.
Recommends for what currently is in libcatalyst-modules-perl and
Suggests for what currently is in libcatalyst-modules-extra-perl)?
> Also, I don't know the packages, but if people out there depend on
> them, I would be hesitant to drop the deprecated packages from the
> archive.
Removing them from the archive doesn't remove them from users'
systems. So no actual breakage. All of the deprecated packages have
either maintained replacements or another (easy) way to accomplish the
same thing so no missing functionality either.
Cheers,
dam
Attachment:
signature.asc
Description: Digital signature