Bug#1057199: debian-policy: express more clearly that Conflicts to not reliably prevent concurrent unpacks

[Sam Hartman]

> "Guillem" == Guillem Jover  writes:

Guillem> At least the dpkg behavior seems entirely
Guillem> correct to me and required for safe upgrades (

Can you help me understand the sentence above?
Where is the case where this behavior is needed for safe upgrades?
(I am asking out of curiosity; I'm guessing it's some corner case with
essential packages, but I would like to understand.)

--Sam

Bug#915583: Bug#1059730: debian-policy: switch to new Debian-conform html theme for Sphinx/reST

[Holger Wansing]

[ Hrrr, I sent this to the wrong bug #1059730; so resending to the correct 
one #915583 for completeness ]


Holger Wansing  wrote (Sun, 31 Dec 2023 10:02:29 +0100):
> Hi Sean and Stéphane,
> 
> Am 30. Dezember 2023 23:43:17 MEZ schrieb Sean Whitton 
> :
> >Possibly some of your changes could be applied on top of that?
[...]
> @Stéphane: 
> The URL is 404 now, could you provide the draft again somewhere?
> ()

Thanks, your files are back online.
They look really good indeed. 
Especially how the menu/sidebar is shown/not shown on small screens 
(smartphones) is fine, that was an open point in my proposal :-)

BTW: I think it would be good to have the 'Next'/'Previous' buttons
at the top additionally to those at the bottom.
The theme supports this via a config option. Simply set

html_theme_options = {
# To get previous/next buttons at the top and the bottom:
'prev_next_buttons_location': 'both'
}

in conf.py.in.


Holger



-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#1057199: debian-policy: express more clearly that Conflicts to not reliably prevent concurrent unpacks

[Guillem Jover]

Hi!

On Fri, 2023-12-15 at 16:40:09 +, Sean Whitton wrote:
> On Fri 01 Dec 2023 at 02:11pm +01, Helmut Grohne wrote:
> > §7.4 currently starts with:
> >
> > When one binary package declares a conflict with another using a
> > Conflicts field, dpkg will refuse to allow them to be unpacked on
> > the system at the same time.
> >
> > I believe this is technically wrong. There are situations where dpkg
> > will allow such unpacks to temporarily co-exist. §6.6 goes into further
> > detail and is accurate.
> 
> Thank you for the detailed report.
> 
> Do the dpkg and apt people think that the bug here is just in Policy, or
> are there any code changes under consideration in response to this work?

I think it is just a documentation issue in the Debian Policy, yes. At
least the dpkg behavior seems entirely correct to me and required for safe
upgrades (and definitely not something like an accidental regression as it
has behaved that way since pretty much the beginning of its git history).

In addition I think the paragraph in §7.4 that states:

,---
A package will not cause a conflict merely because its configuration
files are still installed; it must be at least “Half-Installed”.
`---

could also be clarified that what is stated here does not apply either
to conflicting packages that are being removed, as those will be in
half-installed state. Perhaps as part of this, also make this state
change explicit in §6.6.2.3.

Thanks,
Guillem