Re: Replaces without Breaks or Conflicts harmful?
Helmut Grohne dixit: >> > rng-tools-debian >> >> Also false positive: >> >> Replaces: intel-rng-tools, rng-tools >> Breaks: rng-tools (>= 5migratf), rng-tools (<< 5migrate) >> Conflicts: intel-rng-tools > >This is *not* a false positive, but a real issue. It replaces any >rng-tools, but breaks only a subset. This would have to be fixed to No, because the not-broken subset Depends on rng-tools-debian. (It’s a transitional package.) So, while it cannot be seen by “just” inspecting rng-tools-debian, all possible combinations are covered. (Also, the transition is done and rng-tools is gone.) bye, //mirabilos -- /⁀\ The UTF-8 Ribbon ╲ ╱ Campaign against ╳ HTML eMail! Also, ╱ ╲ header encryption!
Re: Replaces without Breaks or Conflicts harmful?
Hi Thorsten,
On Thu, Jul 06, 2023 at 05:26:43PM +, Thorsten Glaser wrote:
> Helmut Grohne dixit:
>
> > openjdk-8 (U)
>
> Should be convered by the Depends lines in the respective
> binary packages, e.g:
>
> Depends: openjdk-8-jre (>= ${source:Version}),
> openjdk-8-jdk (>= ${binary:Version}),
> ${misc:Depends}
> Replaces: openjdk-8-jdk (<< 8u20~b26-1~)
Yes, this is the kind of fpos I was mentioning as expected.
> > rng-tools-debian
>
> Also false positive:
>
> Replaces: intel-rng-tools, rng-tools
> Breaks: rng-tools (>= 5migratf), rng-tools (<< 5migrate)
> Conflicts: intel-rng-tools
This is *not* a false positive, but a real issue. It replaces any
rng-tools, but breaks only a subset. This would have to be fixed to
either drop the version constraint from Breaks (probably wrong) or add
it to Replaces. Can you handle that?
Helmut
Re: Replaces without Breaks or Conflicts harmful?
Helmut Grohne dixit:
> openjdk-8 (U)
Should be convered by the Depends lines in the respective
binary packages, e.g:
Depends: openjdk-8-jre (>= ${source:Version}),
openjdk-8-jdk (>= ${binary:Version}),
${misc:Depends}
Replaces: openjdk-8-jdk (<< 8u20~b26-1~)
> rng-tools-debian
Also false positive:
Replaces: intel-rng-tools, rng-tools
Breaks: rng-tools (>= 5migratf), rng-tools (<< 5migrate)
Conflicts: intel-rng-tools
bye,
//mirabilos
--
Gestern Nacht ist mein IRC-Netzwerk explodiert. Ich hatte nicht damit
gerechnet, darum bin ich blutverschmiert… wer konnte ahnen, daß SIE so
reagier’n… gestern Nacht ist mein IRC-Netzwerk explodiert~~~
(as of 2021-06-15 The MirOS Project temporarily reconvenes on OFTC)
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
