Re: Another take on package relationship substvars
Hi!
On Thu, 2024-02-22 at 19:32:21 +0100, Niels Thykier wrote:
> Our current way of dealing with package relationship substvars such as
> ${misc:Depends} has been annoying me for a while. As it is, we are stuck in
> this way setup where the "Depends" field in debian/control is de facto
> mandatory. It is an RC bug (waiting to happen) if you omit ${misc:Depends}
> or, for arch:any packages, ${shlib:Depends} from the dependency field.
>
> Personally, I feel we have this weird setup where we have tooling that will
> scream at you if you forget. But I lack a compelling reason for why we need
> tooling to remind us when we could just as well have tooling solve this
> problem for us.
> Additionally, our tooling for reminding us rarely knows about anything but
> the 2-3 standard substvars everyone uses even though we should get reminders
> for other substvars like ${python3:Depends}, ${gir:Depends}, etc.
> Particularly the rules for when a substvars is applicable turns out to be
> quite non-trivial.
>
> I have given this some thought and I think I have a conceptually idea for
> how to solve this, which I will go over in this email.
Right, this is annoying. This was actually brought up some time
ago (2010) in debian-devel as part of #597340. There was not much
reaction at the time (one good, a couple bad).
> # How do we get here?
>
> High level, any helper framework above dpkg can provide this feature if it
> wants to. It is basically a question of parsing d/*.substvars to figure out
> which substvars are relevant, compute a new field from substvars file + the
> static provided data from d/control, and then passing -DField=<...> to
> dpkg-gencontrol.
>
> There are probably a bunch of nitty gritty implementation details in
> practice, but the overall approach stands.
>
> I think each helper stack (debhelper, cdbs, debputy, etc.) would define
> their own rule set for how to get there. As an example, I could see this be
> the new default in the next debhelper compat level, possibly with a way to
> be early adopter on existing compat levels.
If we agree we want this implicit mechanism of adding some substvars
to fields, then doing it in helpers seems like a suboptimal path, as
each one would need to replicate the logic, and implement substvar
substitution logic. I think if this is to be done, it should be done
at the dpkg-dev level.
Some time ago Dpkg::Substvars got support for optional substvars via
the ?= operator (prompted by you! :). I've started a WIP dpkg branch
and will try to finish implementing something for this tomorrow:
https://git.hadrons.org/cgit/debian/dpkg/dpkg.git/log/?h=next/substvars%2b%2b
For now I've added a new (tentative) operator $=, that would declare
the variable is to be implicitly applied. Then the generator can
select whether to use old or new semantics.
> ## Alternative solutions
>
> We could also make unused substvars a hard failure (FTBFS). Personally, I
> feel auto-managing them will be less painful for users. But if the consensus
> goes down this direction, then I would be behind it as it is still better
> than the status quo in my book.
I also implemented in that branch another operator !=, which marks a
substvar as required, so failure to use it will generate an error. I
might have to move the error emission into some other function that
is not called warn_about_unused() though… :)
> That is my proposal for how Debian contributors can spend less mental effort
> tracking relationship substvars and use their new spare mental capacity
> providing value for our users. Thanks for reviewing the proposal and any
> feedback you might have for making relationship substvars be less annoying
> for users and Debian as a whole.
Personally I think I agree with this being a problem and with a
potential solution for this based on implicit substvars. But I'm not
sure I agree at the layer this needs to be implemented. :) I think
going with explicit operators might be what was missing from the
earlier proposal and calm people's qualms about the too much magic
perception. And if there's no major push back on the overall idea
I'm happy to pursue this directly in dpkg-dev.
Thanks,
Guillem
Reply to: