Re: Bug#747628: perl: module deprecations / removals in 5.20
On Tue, May 20, 2014 at 08:50:26AM +0300, Damyan Ivanov wrote:
> > I think NEWS.Debian is appropriate. It's certainly used for things
> > that people generally care about less (such as all new CAs in the
> > ca-certificates package), and people have to make an intentional choice to
> > install apt-listchanges to see the upgrade notifications. I think this is
> > exactly the sort of situation that NEWS.Debian was intended for: a
> > backwards-incompatible change in the packaging.
>
> Thanks. This convinces me. I guess I erred on the "don't possibly harm
> anyone" side.
apt-listchanges and perl are Priority:standard, "installed by default if
the user doesn't select anything else" (Policy 2.5). As Damyan pointed
out, perl is at 99.5% in popcon stats. I see apt-listchanges is at 78.1%.
I don't have numbers to back this up, but I think it's safe to say that
an overwhelming majority of our users are not Perl developers.
So almost 80% of our users have perl and apt-listchanges installed but
mostly don't care about this bit of news. I don't think it's appropriate
to use NEWS.Debian in this context.
I don't particularly like doing it even just for unstable: a majority
of sid users probably aren't perl developers either.
> > I vote for documenting this in NEWS.Debian, retaining Depends
> > *maybe* for one release at most, and then downgrading to at least
> > Recommends with a goal of removing the dependency entirely in the
> > long run.
>
> Niko commented on IRC that removal of automatically installed packages
> that are no longer depended on is fine, since apt/aptitude gives
> a warning about this, IOW there is no silent breakage. And if people
> blindly click "Next>>" it's not something we can fix.
Right. I think there's a difference between modules vanishing silently on
'apt-get dist-upgrade' (because they were removed from perl but nothing
is installed to replace them), and modules vanishing with a warning on
'apt-get autoremove' (where apt explicitly says it's going to remove
the separate package.)
So I think it's useful to keep the dependency/recommendation for one
release cycle but remove it after that. I definitely don't want to
carry it forever.
> Another point that Niko raised and with whis I tend to agree is that
> Recommends may be better than a hard dependency since that would
> satisfy the needs of the people that care more about disk size than
> about safety
Yes. I think if people ignore recommendations they have chosen to
trade safety for disk space savings. So a recommendation seems
adequate to me.
--
Niko Tyni ntyni@debian.org
Reply to: