Your message dated Sun, 31 May 2020 19:03:35 +0300
with message-id <[email protected]>
and subject line Re: Bug#753002: perl: deprecated modules and Replaces entries
has caused the Debian Bug report #753002,
regarding perl: deprecated modules and Replaces entries
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
753002: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=753002
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: perl
Version: 5.20.0-1
We had a discussion with Jonas on IRC about the Replaces/Provides/Breaks
dance we're doing with separately packaged modules, and a question
about the Replaces entries with deprecated modules came up.
For instance, 5.20.0-1 is doing this for Module::Build :
Recommends: libmodule-build-perl
Breaks: libmodule-build-perl (<< 0.420500)
Replaces: libmodule-build-perl
(note that we don't Provide libmodule-build-perl anymore because it's
now deprecated and will be removed in 5.22.)
I'm not quite sure if the Replaces is correct here. I assume it's
for policy 7.6.2 ("Replacing whole packages, forcing their removal"):
Second, Replaces allows the packaging system to resolve which package
should be removed when there is a conflict (see Conflicting binary
packages - Conflicts, Section 7.4).
although I'm not quite sure if Breaks and Conflicts are synonymous here.
Clearly, if it comes to a choice between removing libmodule-build-perl
or perl-modules, the former should be preferred. But what we really
want in this case is an upgrade of libmodule-build-perl (unlike in the
non-deprecated case, where it's fine to remove the separate package.)
So I wonder if we should drop the Replaces too.
This probably needs some testing. Keeping the Replaces is perhaps
the more conservative approach, as we did a successful 5.18 transition
where for instance libmodule-pluggable-perl was handled the way
libmodule-build-perl currently is.
--
Niko Tyni [email protected]
--- End Message ---
--- Begin Message ---
On Sat, Jun 28, 2014 at 03:16:41PM +0300, Niko Tyni wrote:
> Package: perl
> Version: 5.20.0-1
>
> We had a discussion with Jonas on IRC about the Replaces/Provides/Breaks
> dance we're doing with separately packaged modules, and a question
> about the Replaces entries with deprecated modules came up.
>
> For instance, 5.20.0-1 is doing this for Module::Build :
>
> Recommends: libmodule-build-perl
> Breaks: libmodule-build-perl (<< 0.420500)
> Replaces: libmodule-build-perl
>
> (note that we don't Provide libmodule-build-perl anymore because it's
> now deprecated and will be removed in 5.22.)
>
> I'm not quite sure if the Replaces is correct here. I assume it's
> for policy 7.6.2 ("Replacing whole packages, forcing their removal"):
[...]
> So I wonder if we should drop the Replaces too.
>
> This probably needs some testing. Keeping the Replaces is perhaps
> the more conservative approach, as we did a successful 5.18 transition
> where for instance libmodule-pluggable-perl was handled the way
> libmodule-build-perl currently is.
We haven't done the Recommends thing after 5.20. Seems like it's time
to close this.
--
Niko Tyni [email protected]
--- End Message ---
