On Fri, Mar 08, 2024 at 07:38:01AM +0100, Rene Engelhard wrote: > Hi, > > Am 08.03.24 um 00:12 schrieb Eric Valette: > > On 07/03/2024 21:16, Rene Engelhard wrote: > > ct more people. > > > > > > But not so much for dependency issues like this. Which is my sole > > > point. In 99,9% of cases this won't even migrate to testing. And > > > unstable won't be released - testing will. > > > > What is your point? Without known bugs or new versions packages migrate > > from unstable to testing automatically. > > > > > > > > You should be happy people debug code > > > > > > *debug code*, yes. debug *actual* (dependency) issues, yes. > > > > I did my part for example with this one, that maintainer denied first > > but fixed later in his next upload as suggested... > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065349 > > Well, you haven't seen the various discussion how to fix smbclient on IRC... > > Not really. This is an affect of > > * d/genshlibs: run dh_makeshlibs on libsmbclient0 > (Closes: #1065349) > > where the side effect is that one gets the provides via > > Package: libsmbclient0 > Provides: ${t64:Provides} > X-Time64-Compat: libsmbclient > > That is the correct fix (with a similar result of what you suggests), not > what you suggested in the first mail, though. > > Besides that your wrote: > > You cannot install libsmbclient0 without breaking libsmbclient if the > > version of libsmbclient is not at least 2:4.19.5+dfsg-3. It will then > > replace libsmbclient. > > > > BUT the package libsmbclient 2:4.19.5+dfsg-3 is never going to be > > generated nor latter versions unless the names change back to > > libsmbclient. So the condition will never happen. > > > That is plain wrong. Breaks: is not waiting for anything be there. It's just > a lesser version of Conflicts
That's how it works in practice with apt, but it's theoretically incorrect. Breaks should only be used for forcing upgrades of packages, and not as a "lesser Conflicts" because, while apt does enforce removal of Breaks, this is not part of the policy or dpkg - the dpkg behavior would be to deconfigure the package and leave it around in a half installed state. Hence you should always have an upgrade to install such that the package is fully installed again; or use a Conflicts to make sure it is fully removed. Also note the Policy requires explicit use of Conflicts + Replaces for fully replacing a package. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en
