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
signature.asc
Description: OpenPGP digital signature