On Thu, Feb 22, 2024 at 08:52:36PM +0100, IOhannes m zmölnig wrote:
> Am 22. Februar 2024 20:25:32 MEZ schrieb Boyuan Yang <by...@debian.org>:
> >在 2024-02-22星期四的 19:32 +0100，Niels Thykier写道：
> >> I am omitting Breaks, Conflicts, and Replaces because I am not aware of
> >> any users of these at the moment. I am open to adding them, if there is
> >> a strong use-case.
Once upon a time, dh_suidmanager recommended that people add "Conflicts:
suidmanager (<< 0.50)" when migrating away from it to normal
statoverrides. With your proposal, I can imagine it having made sense
to do that (or at least something similar) using substvars. And while
dbgsym control files aren't actually generated using substvars,
dh_gencontrol does use -DReplaces and -DBreaks when generating them, and
it's not too hard to imagine something similar being needed for some
kind of automatic transition.
I'd include these three fields, if you're going to do this. I think I'm
in favour, as long as testing indicates that it doesn't cause much
breakage.
> While I like the idea in general, I wonder how I could override these
> automatic additions.
> I think there are some packages that even demote `${shlibs:Depends}` to
> Recommends.
That rings a bell, but I can't think where it was.
One thing I've done occasionally when I had no better option is to
postprocess the output of dpkg-shlibdeps. For example:
https://salsa.debian.org/ssh-team/openssh/-/blob/b9671cc7/debian/adjust-openssl-dependencies
https://salsa.debian.org/ssh-team/openssh/-/blob/b9671cc7/debian/rules#L217-219
(Possibly obsolete now - I should check. But anyway.)
If you really had to, then postprocessing debian/*.substvars to remove a
particular field would be simpler than that - probably just two lines in
debian/rules. I think that would be tolerable if the need is as rare as
I think it is, though of course it'd be worth documenting.
--
Colin Watson (he/him) [cjwat...@debian.org]
