On Thursday, October 10th, 2024 at 8:56 AM, Helmut Grohne <hel...@subdivi.de> 
wrote:

> 

> 

> Hi Daniel,
> 

> Is there any reason that you reach out privately to me? I generally
> prefer having technical conversations in public and a simple way would
> be to copy this conversation to the bug #1084819. You may publish or
> quote my reply there.
> 


Hi Helmut,

Thanks for your reply! Per your recommendation, I'm forwarding this 
conversation in the public bug.

> On Thu, Oct 10, 2024 at 04:36:02AM +0000, Daniel Markstedt wrote:
> 

> > I read the Debian Policy in question to figure out the best way to resolve 
> > this, and chose the Breaks relationship.
> > https://www.debian.org/doc/debian-policy/ch-relationships.html#packages-which-break-other-packages-breaks
> 

> 

> In my experience, reading policy does not give the full story in many
> situations as it cuts down on the why and the context to keep its size
> manageable.
> 

> For your question, I suggest also consulting:
> https://wiki.debian.org/PackageTransition
> 

> > This is the specific syntax in debian/control:
> > Enhances: netatalk (>= 4.0.0~ds-1)Breaks: netatalk (<< 4.0.0~ds-1)
> > https://salsa.debian.org/netatalk-team/netatalk/-/blob/debian/latest/debian/control
> > 

> > However, your integration tests still detect an undeclared conflict:
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1084819
> > 

> > So at this point I'm unclear as to whether 1. I'm misusing Breaks (syntax 
> > error etc) here or 2. you're arguing that Breaks is insufficient and that 
> > Conflicts must be used.
> 

> 

> Reading closely, the diagnostics do not even mention Breaks. The Breaks
> declaration merely states that two packages cannot be used (configured)
> together. The diagnostics here are about unpacking and packages can be
> concurrently unpacked even when declaring Breaks. This is why the
> report came back.
> 

> Now equipped with this, I am positive that you can work out the correct
> solution using the wiki page above and if it takes you more than 15
> minutes, consider asking me again for a longer answer.
> 

> Helmut

Reading the Package Transition Guide, I believe case#7 is appropriate for this 
scenario: In simple terms, the old netatalk 3.x deb package contained daemons 
and tools; The new netatalk 4.x deb package contains only daemons, and the 
netatalk-tools 4.x deb package contains only tools. Therefore, I would say the 
following relationship declarations in netatalk-tools should get us the wanted 
behavior...

Enhances: netatalk (>= 4.0.0~ds-1)
Breaks: netatalk (<< 4.0.0~ds-1)
Replaces: netatalk (<< 4.0.0~ds-1)

Would you say that the new netatalk 4.x package also should have this Replaces 
declaration? Or would this be redundant for a new package sharing the same name 
as the old package?

Regards,
Daniel

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to