Sean Whitton <[email protected]> writes: > Hello, > > On Wed 18 Jun 2025 at 07:07pm -07, Xiyue Deng wrote: > >> Ah didn't think about that. I think it's better than using control.in >> in general, though there are the "unused" warning on other packages >> (using "?=" doesn't seem to help). > > I don't follow. >
Excerpt from build log (basically it shows a warning of substitution
variable unused for all binary packages except emacs-common where it's
used.)
,----
| ...
| debian/rules override_dh_gencontrol
| make[1]: Entering directory '/build/reproducible-path/emacs-30.1+1'
| dh_gencontrol -- -Tdebian/emacs-substvars
| dpkg-gencontrol: warning: package emacs: substitution variable
${emacs:Provides} unused, but is defined
| dpkg-gencontrol: warning: package emacs-pgtk: substitution variable
${emacs:Provides} unused, but is defined
| dpkg-gencontrol: warning: package emacs-pgtk: substitution variable
${emacs:Provides} unused, but is defined
| dpkg-gencontrol: warning: package emacs-lucid: substitution variable
${emacs:Provides} unused, but is defined
| dpkg-gencontrol: warning: package emacs-bin-common: substitution variable
${emacs:Provides} unused, but is defined
| dpkg-gencontrol: warning: package emacs-lucid: substitution variable
${emacs:Provides} unused, but is defined
| dpkg-gencontrol: warning: package emacs-bin-common: substitution variable
${emacs:Provides} unused, but is defined
| dpkg-gencontrol: warning: package emacs-nox: substitution variable
${emacs:Provides} unused, but is defined
| dpkg-gencontrol: warning: package emacs-nox: substitution variable
${emacs:Provides} unused, but is defined
| dpkg-gencontrol: warning: package emacs-gtk: substitution variable
${emacs:Provides} unused, but is defined
| dpkg-gencontrol: warning: package emacs-el: substitution variable
${emacs:Provides} unused, but is defined
| dpkg-gencontrol: warning: package emacs-gtk: substitution variable
${emacs:Provides} unused, but is defined
| ...
`----
>> One advantage of generating d/control that I like is that we can see the
>> provide list directly and can inspect the diff on regeneration. To get
>> something similar, I have each package version pair as one line of
>> comment in the substvars file before setting emacs:Provides (the
>> substitute variable I'm using for now). This way we get something
>> similar.
>
> True.
>
>> Somehow I cannot use debian/substvars or debian/<package>.substvars
>> (which probably got removed by "clean") and need to use
>> override_dh_gencontrol to pass the generated substvars file (I'm using
>> debian/emacs-substvars). Let me know if there is a better way.
>
> I don't know how to do it off the top of my head, either. But I'm sure
> it can be done. Look at how dh_elpa does it, I guess?
>
I think dh_elpa generates the substvars files during the process
(definitely after dh_auto_clean) so that it's not affected. The current
work around is not too bad, though.
>>> I see you're using package--builtin-versions. I'm not happy to be using
>>> an internal variable -- it got us in trouble before!
>>>
>>
>> Current there seems to be no way to get the builtin package info
>> otherwise. Fortunately we can easily verify whether it still works by
>> running "debian/rules debian-sync" and inspect the diff in
>> debian/emacs-substvars.
>>
>> Meanwhile I'll try to file a wishlist bug upstream and migrate in
>> future.
>
> I'm not up for merging that, I'm afraid. I think we need a public
> function first.
>
I have filed the bug upstream[1], but that would be for 31.x. I was
hoping this would be useful for Trixie to handle security updates,
though it may have already been a bit too late for that.
> --
> Sean Whitton
[1] https://debbugs.gnu.org/78844
--
Regards,
Xiyue Deng
signature.asc
Description: PGP signature
