Your message dated Sun, 7 Jun 2026 03:14:09 +0200
with message-id <[email protected]>
and subject line Re: Bug#597340: dpkg-gencontrol: implicit substvar at the end 
of every field
has caused the Debian Bug report #597340,
regarding dpkg-gencontrol: implicit substvar at the end of every field
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)


-- 
597340: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=597340
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: dpkg-dev
Version: 1.15.8.5
Severity: wishlist

Every time that debhelper needs to adjust a dependency it provides a new
substvar and the maintainer needs to put it in the right field. I was
thinking that we could avoid the second half if some specific substvars
was added at the end of every field.

dpkg-gencontrol could be modified to always append the value of
${implicit:<fieldname>} at the end of the corresponding field. Maybe
we should even support multiple substvars (say
${implicit:<fieldname>:<origin>}) so that there's no coordination problem
if multiple tools want to add something at the end of the same field.

This would even make it possible for debhelper to add dependencies that
are not at all present in debian/control, like for example Breaks... this
would have been handy for example when several dh_* tools have stopped
doing their work on the assumption that the triggerized version of
the postinst snippet was available on the system. With a break, it could
ensure that the relevant package had been upgraded...

With such a system, the ${misc:Depends} that we are currently adding
everywhere would not have been needed.

CCing -devel and Joey Hess to have some input on this idea. Do you think
it would be useful ? Do you have comments and suggestions ?

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer ◈ [Flattr=20693]

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
                      ▶ http://RaphaelHertzog.fr (Français)



--- End Message ---
--- Begin Message ---
Version: 1.23.0

On Sat, 2010-09-18 at 21:23:51 +0200, Raphaël Hertzog wrote:
> Package: dpkg-dev
> Version: 1.15.8.5
> Severity: wishlist

> Every time that debhelper needs to adjust a dependency it provides a new
> substvar and the maintainer needs to put it in the right field. I was
> thinking that we could avoid the second half if some specific substvars
> was added at the end of every field.
> 
> dpkg-gencontrol could be modified to always append the value of
> ${implicit:<fieldname>} at the end of the corresponding field. Maybe
> we should even support multiple substvars (say
> ${implicit:<fieldname>:<origin>}) so that there's no coordination problem
> if multiple tools want to add something at the end of the same field.
> 
> This would even make it possible for debhelper to add dependencies that
> are not at all present in debian/control, like for example Breaks... this
> would have been handy for example when several dh_* tools have stopped
> doing their work on the assumption that the triggerized version of
> the postinst snippet was available on the system. With a break, it could
> ensure that the relevant package had been upgraded...
> 
> With such a system, the ${misc:Depends} that we are currently adding
> everywhere would not have been needed.
> 
> CCing -devel and Joey Hess to have some input on this idea. Do you think
> it would be useful ? Do you have comments and suggestions ?

This got somehow implemented with the implicit substvars defined in
deb-substvars(5) by the $= operator. I don't think further implicitness
would be wise here, so the current support seems sufficient to me. And
I'm thus closing this report now.

Thanks,
Guillem

--- End Message ---

Reply via email to