Re: Replaces without Breaks or Conflicts harmful? [was: Re: Policy consensus on transition when removing initscripts.]
Hi, On 6/29/23 04:49, Helmut Grohne wrote: * Package A 1.0-1 is installed providing file F. * File F is moved to package B as of package A 1.0-3. * User installs package B, which replaces the file in package A. * User uninstalls package B. F is now gone, even though it's supposed to be still shipped by A 1.0-1. I am convinced by this. I think this is a sufficiently bad footgun to simply forbid Replaces that are not covered by a suitable Breaks or Conflicts relation. That is already in Policy 7.6.1, with a footnote that gives exactly this explanation. Simon
Re: Replaces without Breaks or Conflicts harmful? [was: Re: Policy consensus on transition when removing initscripts.]
On Thu, 29 Jun 2023 at 13:34, Helmut Grohne wrote: > > Hi Bas, > > On Thu, Jun 29, 2023 at 08:19:51AM +0200, Sebastiaan Couwenberg wrote: > > On 6/28/23 21:49, Helmut Grohne wrote: > > > Debian GIS Project > > > postgis > > > qgis > > > > Why is postgis on this list? > > > > $ grep -c Replaces debian/control* > > debian/control:0 > > debian/control.in:0 > > Thanks for asking. You identified another source of false positives that > slipped my mind when doing the analysis. The underlying data source did > not use unstable, but every suite from bullseye to experimental > including -security and -backports. As it happens, bookworm's > postgresql-15-postgis-3-scripts has versioned Replaces that are not > matched with Breaks or Conflicts. I don't think we are going to fix that > in bookworm and you've fixed it in unstable. So yeah, this list has more > false positives than originally assumed. In case it's useful, src:dpdk is also a false positive, I suspect because the versions in the breaks vs replaces are slightly different - probably clerical mistakes, like a missing '~'. > I could improve the numbers, but to me the numbers I've given being a > tight upper bound seems good enough and lintian.debian.org will give us > precise and current numbers once my patch is merged. Does that seem > sensible to you as well? Sadly, as I found out recently for the scripts mbf, lintian.d.o is borken and has ~2 years old stale data. We should probably consider taking it down, given it appears fully working and can be queried, but just returns stale data with no indication that it is stale on the face of it, without manual checks. Kind regards, Luca Boccassi
Re: Replaces without Breaks or Conflicts harmful? [was: Re: Policy consensus on transition when removing initscripts.]
On 6/29/23 12:32, Helmut Grohne wrote: On Thu, Jun 29, 2023 at 08:19:51AM +0200, Sebastiaan Couwenberg wrote: On 6/28/23 21:49, Helmut Grohne wrote: Debian GIS Project postgis qgis Why is postgis on this list? $ grep -c Replaces debian/control* debian/control:0 debian/control.in:0 Thanks for asking. You identified another source of false positives that slipped my mind when doing the analysis. The underlying data source did not use unstable, but every suite from bullseye to experimental including -security and -backports. As it happens, bookworm's postgresql-15-postgis-3-scripts has versioned Replaces that are not matched with Breaks or Conflicts. I don't think we are going to fix that in bookworm and you've fixed it in unstable. So yeah, this list has more false positives than originally assumed. Thanks for clarifying your data sources. FWIW, qgis is fixed in git. I could improve the numbers, but to me the numbers I've given being a tight upper bound seems good enough and lintian.debian.org will give us precise and current numbers once my patch is merged. Does that seem sensible to you as well? If you intend to file bugs you should only look at unstable & experimental. For the sake of argument your list is fine. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Re: Replaces without Breaks or Conflicts harmful? [was: Re: Policy consensus on transition when removing initscripts.]
Hi Bas, On Thu, Jun 29, 2023 at 08:19:51AM +0200, Sebastiaan Couwenberg wrote: > On 6/28/23 21:49, Helmut Grohne wrote: > > Debian GIS Project > > postgis > > qgis > > Why is postgis on this list? > > $ grep -c Replaces debian/control* > debian/control:0 > debian/control.in:0 Thanks for asking. You identified another source of false positives that slipped my mind when doing the analysis. The underlying data source did not use unstable, but every suite from bullseye to experimental including -security and -backports. As it happens, bookworm's postgresql-15-postgis-3-scripts has versioned Replaces that are not matched with Breaks or Conflicts. I don't think we are going to fix that in bookworm and you've fixed it in unstable. So yeah, this list has more false positives than originally assumed. I could improve the numbers, but to me the numbers I've given being a tight upper bound seems good enough and lintian.debian.org will give us precise and current numbers once my patch is merged. Does that seem sensible to you as well? Helmut
Re: Replaces without Breaks or Conflicts harmful? [was: Re: Policy consensus on transition when removing initscripts.]
On 6/28/23 21:49, Helmut Grohne wrote: Debian GIS Project postgis qgis Why is postgis on this list? $ grep -c Replaces debian/control* debian/control:0 debian/control.in:0 Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
