Bug#1050322: Partial versus complete replacement of a package by another

[Edward Little]

Please remove the following email address:  e.little...@gmail.com

On Sat, Sep 9, 2023 at 6:51 PM Russ Allbery  wrote:

> julien.pu...@gmail.com writes:
>
> > Oh. I think I had two problems:
> > (1) thinking "Replaces" meant "replaces" ;
> > (2) thinking d/control controlled packages.
>
> > Let me try to see if I'm getting at something:
>
> > (*) Replaces doesn't really mean "can be used in place of"
> > -- that would be expressed with Breaks+Provides.
>
> > (*) Replaces shouldn't come without Breaks, but doesn't imply it
> > so we have to put in both (why?).
>
> Yes, this is a good question.  I recently was confused about this myself
> despite having worked on Debian and maintained Policy and, at times,
> Lintian for years, which implies that we don't do a very good job of
> documenting the ins and outs of this.
>
> https://lists.debian.org/debian-devel/2023/06/msg00354.html is the best
> explanation of this that I've seen.  The short summary is that the one
> case where Breaks is not required is if the package with Replaces also
> depends on a new version of the package that it is replacing.  This
> prevents the scenario described in the footnote.
>
> The other thing that's worth noting is that sometimes you want Breaks and
> sometimes you want Conflicts, and both Breaks and Conflicts are useful
> without Replaces for other reasons, so none of them can really imply any
> of the others.
>
> I also saw your other bug (#1050221) about promoting that footnote to the
> main text.  That's a partial fix, but I think we should include some
> portion of Helmut's explanation directly in Policy as well.  (We sort of
> say this, but we're not nearly as explicit about it as we could be, and we
> don't use normative language.)
>
> > (*) In 7.6.1's example, what happens if the system has foo 1.2-2 and
> > the user tries to install foo-data 1.2-3? Do we end up with foo 1.2-2
> > and foo-data 1.2-3 unpacked and apt/dpkg complaining it can't configure
> > them or does it refuse with a clear error message?
>
> It refuses to begin the operation because foo-data 1.2-3 breaks foo 1.2-2
> and foo 1.2-2 is currently configured.  foo 1.2-2 has to be unconfigured
> first before the installation of foo-data 1.2-3 can procede.  (This is
> documented in Policy 7.3 where Breaks is discussed.)
>
> What normally happens is that users use apt rather than dpkg directly.  I
> believe apt will force an upgrade of foo because it sees that it is broken
> by foo-data and will not allow installation of foo-data without either
> upgrading or removing foo.  (dpkg does not do this because dpkg in general
> operates on only the packages it's told to operate on and doesn't expand
> the scope of one invocation to change other packages.)
>
> --
> Russ Allbery (r...@debian.org)  
>
>

Bug#1050322: Partial versus complete replacement of a package by another

[Russ Allbery]

julien.pu...@gmail.com writes:

> Oh. I think I had two problems:
> (1) thinking "Replaces" meant "replaces" ;
> (2) thinking d/control controlled packages.

> Let me try to see if I'm getting at something:

> (*) Replaces doesn't really mean "can be used in place of"
> -- that would be expressed with Breaks+Provides.

> (*) Replaces shouldn't come without Breaks, but doesn't imply it
> so we have to put in both (why?).

Yes, this is a good question.  I recently was confused about this myself
despite having worked on Debian and maintained Policy and, at times,
Lintian for years, which implies that we don't do a very good job of
documenting the ins and outs of this.

https://lists.debian.org/debian-devel/2023/06/msg00354.html is the best
explanation of this that I've seen.  The short summary is that the one
case where Breaks is not required is if the package with Replaces also
depends on a new version of the package that it is replacing.  This
prevents the scenario described in the footnote.

The other thing that's worth noting is that sometimes you want Breaks and
sometimes you want Conflicts, and both Breaks and Conflicts are useful
without Replaces for other reasons, so none of them can really imply any
of the others.

I also saw your other bug (#1050221) about promoting that footnote to the
main text.  That's a partial fix, but I think we should include some
portion of Helmut's explanation directly in Policy as well.  (We sort of
say this, but we're not nearly as explicit about it as we could be, and we
don't use normative language.)

> (*) In 7.6.1's example, what happens if the system has foo 1.2-2 and
> the user tries to install foo-data 1.2-3? Do we end up with foo 1.2-2
> and foo-data 1.2-3 unpacked and apt/dpkg complaining it can't configure
> them or does it refuse with a clear error message?

It refuses to begin the operation because foo-data 1.2-3 breaks foo 1.2-2
and foo 1.2-2 is currently configured.  foo 1.2-2 has to be unconfigured
first before the installation of foo-data 1.2-3 can procede.  (This is
documented in Policy 7.3 where Breaks is discussed.)

What normally happens is that users use apt rather than dpkg directly.  I
believe apt will force an upgrade of foo because it sees that it is broken
by foo-data and will not allow installation of foo-data without either
upgrading or removing foo.  (dpkg does not do this because dpkg in general
operates on only the packages it's told to operate on and doesn't expand
the scope of one invocation to change other packages.)

-- 
Russ Allbery (r...@debian.org)  

Bug#1050322: Partial versus complete replacement of a package by another

[Bill Allombert]

On Wed, Aug 23, 2023 at 09:22:41AM +0200, julien.pu...@gmail.com wrote:
> Package: debian-policy
> Version: 4.6.2.0
> Severity: normal
> 
> Hi,
> 
> over at bug #1050027 there is a discussion of applicable policy when
> splitting a package. I'll first explain what the bug is about and then
> why that's a problem with the Policy.
> 
> The src:mathcomp-analysis package provided a single binary package
> libcoq-mathcomp-analysis until 0.6.3-2 ; with 0.6.4-1, it's now
> providing two binary packages libcoq-mathcomp-analysis and libcoq-
> mathcomp-classical. The binary package libcoq-mathcomp-analysis Depends
> on libcoq-mathcomp-classical (= ${binary:Version}). And with 0.6.4-1,
> that Depends was the only information, so of course file conflicts
> weren't handled correctly, and that is what #1050027 is about.
> 
> In src:mathcomp-analysis 0.6.4-2, I declared that libcoq-mathcomp-
> classical Breaks libcoq-mathcomp-analysis (<< 0.6.4) and closed the
> bug. It was swiftly re-opened because I hadn't used Breaks+Replaces
> according to Policy 7.6.1. But I don't want to use Replaces as libcoq-
> mathcomp-classical isn't a *complete* replacement for libcoq-mathcomp-
> analysis (<< 0.6.4) -- it only provides a small part of it!
> 
> 
> So what does the Policy actually say?

The main purpose of Replaces: is that dpkg normally does not allow two 
different packages
to provide the same files. When the second package is installed dpkg will issue 
an
overwrite error, unless the second package has the same name as the first or 
when
the second package Replaces: the first.

Mostly there are two cases:
1/ you decide to move the file /usr/share/foo/data from foo to foo-data:
foo-data needs to Replaces: foo for at least one release.

2/ you decide to rename the package foo to foo1:
foo1 need to Replaces: foo for at least one release.

Cheers,
Bill

Bug#1050322: Partial versus complete replacement of a package by another

[julien . puydt]

Hi,

Le mercredi 23 août 2023 à 08:45 +0100, Simon McVittie a écrit :

> No, the central misunderstanding here is that you think Replaces will
> have the effect of instructing dpkg to remove the replaced package
> completely, which is not the case.

Oh. I think I had two problems:
(1) thinking "Replaces" meant "replaces" ;
(2) thinking d/control controlled packages.

Let me try to see if I'm getting at something:

(*) Replaces doesn't really mean "can be used in place of"
-- that would be expressed with Breaks+Provides.


(*) Replaces shouldn't come without Breaks, but doesn't imply it
so we have to put in both (why?).


(*) Breaks+Replaces is partial replacement.


(*) A complete replacement can be achieved with:

  (+) just the same package name (the most usual situation,
  explicit in d/control)

  (+) Breaks+Replaces and all files of the other package are
  overriden (triggers removal of the other, *not* seen in
  d/control!);

  (+) Conflicts+Replaces (forcing removal of the other,
  explicit in d/control).


(*) In 7.6.1's example, what happens if the system has foo 1.2-2 and
the user tries to install foo-data 1.2-3? Do we end up with foo 1.2-2
and foo-data 1.2-3 unpacked and apt/dpkg complaining it can't configure
them or does it refuse with a clear error message?

Thanks,

J.Puydt

Bug#1050322: Partial versus complete replacement of a package by another

[Simon McVittie]

On Wed, 23 Aug 2023 at 09:22:41 +0200, julien.pu...@gmail.com wrote:
> In src:mathcomp-analysis 0.6.4-2, I declared that libcoq-mathcomp-
> classical Breaks libcoq-mathcomp-analysis (<< 0.6.4) and closed the
> bug. It was swiftly re-opened because I hadn't used Breaks+Replaces
> according to Policy 7.6.1. But I don't want to use Replaces as libcoq-
> mathcomp-classical isn't a *complete* replacement for libcoq-mathcomp-
> analysis (<< 0.6.4) -- it only provides a small part of it!

It seems you've misunderstood what Replaces means: it doesn't mean
"is a complete drop-in replacement for". (That would need a Provides too.)

Policy 7.6.1 talks about an old package foo which has been split into
new packages foo and foo-data, which seems like your situation with the
names changed?

> The problem is with section 7.6 on how to use Replaces: indeed, the
> very first paragraph of 7.6 mentions "two distinct purposes", partial
> and complete replacement... but the rest of the section is all about
> complete replacement

What I see in that section is:

7.6. Overwriting files and replacing packages - Replaces
7.6.1. Overwriting files in other packages
7.6.2. Replacing whole packages, forcing their removal

7.6.2 is about complete replacement, so by a process of elimination,
7.6.1 ought to be about partial replacement (and it is: it talks about
"The new version of the package foo", which wouldn't exist if foo-data
had completely superseded it).

> In fact subsection 7.6.1 has an example which looks exactly like
> #1050027, but it looks wrong: if foo 1.2-2 is installed on a system and
> foo-data 1.2-3's installation is requested, then because of Breaks dpkg
> will know about the file conflicts and beware, but because of Replaces,
> it will think it's a complete replacement -- foo will disappear if I
> understand well.

No, the central misunderstanding here is that you think Replaces will
have the effect of instructing dpkg to remove the replaced package
completely, which is not the case.

smcv

Bug#1050322: Partial versus complete replacement of a package by another

[julien . puydt]

Package: debian-policy
Version: 4.6.2.0
Severity: normal

Hi,

over at bug #1050027 there is a discussion of applicable policy when
splitting a package. I'll first explain what the bug is about and then
why that's a problem with the Policy.

The src:mathcomp-analysis package provided a single binary package
libcoq-mathcomp-analysis until 0.6.3-2 ; with 0.6.4-1, it's now
providing two binary packages libcoq-mathcomp-analysis and libcoq-
mathcomp-classical. The binary package libcoq-mathcomp-analysis Depends
on libcoq-mathcomp-classical (= ${binary:Version}). And with 0.6.4-1,
that Depends was the only information, so of course file conflicts
weren't handled correctly, and that is what #1050027 is about.

In src:mathcomp-analysis 0.6.4-2, I declared that libcoq-mathcomp-
classical Breaks libcoq-mathcomp-analysis (<< 0.6.4) and closed the
bug. It was swiftly re-opened because I hadn't used Breaks+Replaces
according to Policy 7.6.1. But I don't want to use Replaces as libcoq-
mathcomp-classical isn't a *complete* replacement for libcoq-mathcomp-
analysis (<< 0.6.4) -- it only provides a small part of it!


So what does the Policy actually say?

In section 7.3 it discusses the use of Breaks to avoid file conflicts -
- and on that point it's pretty clear.

The problem is with section 7.6 on how to use Replaces: indeed, the
very first paragraph of 7.6 mentions "two distinct purposes", partial
and complete replacement... but the rest of the section is all about
complete replacement -- and it's using Breaks+Replaces for that. What
relationship fields combination corresponds to *partial* replacement?
As far as I can tell it doesn't say!

Subsection 7.6.1 explains that Replaces without Breaks shouldn't happen
(not clearly enough: #1050221).

In fact subsection 7.6.1 has an example which looks exactly like
#1050027, but it looks wrong: if foo 1.2-2 is installed on a system and
foo-data 1.2-3's installation is requested, then because of Breaks dpkg
will know about the file conflicts and beware, but because of Replaces,
it will think it's a complete replacement -- foo will disappear if I
understand well. The system will stay coherent but the user will have
lost features...

My understanding of relationship fields mechanics is:

| | Breaks   | no Breaks  |
|-+--+|
| Replaces| complete replacement | 7.6.1: no! |
| no Replaces | partial replacement  | very usual |

But that indeed isn't in the Policy per se, so I'm asking for
clarification.

Cheers,

J.Puydt