• Bug#1067767: dpkg-gencontrol: Don't fail on syntax error in removed fie

    From David Kalnischkies@1:229/2 to All on Tue Mar 26 14:30:01 2024
    XPost: linux.debian.bugs.dist
    From: david@kalnischkies.de

    Package: dpkg-dev
    Version: 1.22.6
    Severity: normal
    X-Debbugs-Cc: debhelper@packages.debian.org

    Hi,

    since recently my arch:any package `ycmd` fails to built from source in
    a fresh unstable sbuild environment with at least dpkg 1.22.6 and
    debhelper 13.15.2 (compat 13) while generating the dbgsym package:

    | dh_gencontrol -O--sourcedirectory=/<<BUILDDIR>>/ycmd-0\+20231230\+git9e43034\+ds/cpp -O--builddirectory=/<<BUILDDIR>>/ycmd-0\+20231230\+git9e43034\+ds/ycm_build
    | dpkg-gencontrol: warning: can't parse dependency ycmd-core-version (= )
    | dpkg-gencontrol: warning: Depends field of package ycmd: substitution variable ${misc:Depends} used, but is not defined
    | dpkg-gencontrol: warning: Depends field of package ycmd: substitution variable ${python3:Depends} used, but is not defined
    | dpkg-gencontrol: warning: Depends field of package ycmd: substitution variable ${shlibs:Depends} used, but is not defined
    | dpkg-gencontrol: warning: Recommends field of package ycmd: substitution variable ${misc:Clang-Ver} used, but is not defined
    | dpkg-gencontrol: warning: Provides field of package ycmd: substitution variable ${misc:Core-Ver} used, but is not defined
    | dpkg-gencontrol: warning: can't parse dependency ycmd-core-version (= )
    | dpkg-gencontrol: error: parsing package 'ycmd' Provides field: ycmd-core-version (= ), ycmd-core-version (= 48)
    | dh_gencontrol: error: dpkg-gencontrol -pycmd -ldebian/changelog -T/dev/null -Pdebian/.debhelper/ycmd/dbgsym-root -UPre-Depends -URecommends -USuggests -UEnhances -UProvides -UEssential -UConflicts -DPriority=optional -UHomepage -UImportant -DAuto-Built-
    Package=debug-symbols -UProtected -UBuilt-Using -UStatic-Built-Using -DPackage=ycmd-dbgsym "-DDepends=ycmd (= \${binary:Version})" "-DDescription=debug symbols for ycmd" -DBuild-Ids=dc609a05ca957392f347883f157f1d84a1561dbe -DSection=debug -UMulti-Arch -
    UReplaces -UBreaks returned exit code 25
    | dh_gencontrol: error: Aborting due to earlier error
    | make: *** [debian/rules:19: binary] Error 25

    (`vim-youcompleteme` also from me uses something similar but doesn't
    fail to build – that one is arch:all and doesn't have a -dbgsym)


    The incorrect syntax comes from debian/control containing:
    | Provides: ycmd-core-version (= ${misc:Core-Ver}), […]
    and dpkg-gencontrol being called with -T/dev/null here (by debhelper).


    I am not quite sure if dpkg or debhelper caused this regression with the
    recent changes around substvars, but given that a substvar can only be
    used to modify the contents of a field and can not embed other fields
    in the modification it seems reasonable that if a field is removed from
    the output with -U (or overridden with -D) dpkg-gencontrol should not
    insist on its syntax being correct – or even warn about undefined
    substvars within – as it will have no effect on the output and as
    such this might be considered a feature request potentially fixing
    a regression (and is as such upgraded from wishlist to normal):

    I could easily resolve this error & ignoring the warnings by letting
    the entire provides being generated instead of just the version number
    here as a simple workaround, but given the choice I would prefer what
    I have and it doesn't seem that strange, so others might be effected.


    That might very well be a bug in debhelper (too), as I assume it does
    this dance to have some fields copied from the package to its -dbgsym offspring, which could contain substvars and hence the -T/dev/null might
    be the regression here, but I am not sure as I did not dare too look too
    deeply under the hood (or in version control) for the time being.


    On a sidenote, while writing this, using "misc:Core-Ver" seems silly…
    but deb-substvars(5) doesn't seem to offer a hint at a reasonable naming
    scheme less likely to conflict with future changes. Other packages use "<srcname>:<foo>" which seems more reasonable at a glance, so might that
    be a good suggestion that could be added there?


    Best regards

    David Kalnischkies

    P.S.: I do consider my sbuild setup reasonably normal/standard, so
    I spare you the details, but I am happy to add them if it turns out
    I am more of a unique snowflake here than I am assuming.

    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCgAdFiEE5sn+Q4uCja/tn0GrMRvlz3HQeIMFAmYCyp4ACgkQMRvlz3HQ eIP4IBAApVMaMm3bcTtYWZKPNxU36lIPcQUktt/Gnc+GRJ6fKOXgN+mbWylo3Pzb GGuBqi7C09G5IAAPzfNXgDbm47mI5xMfR9A9aYRi0czPlFSid9YGMyy9PNJ9BQvQ PmQ03fKULYUj6B+o2dPZNQYLP37B+CRpczecXDENlFLblSacaSDtVstFJr7eQF3J AOmaeFLKjm0Ns5h5Y7fqwZrkJISWo3FHi4mdEQ+2jfbPOTWU6X/Kd11orEMhaTXF MscTvQjmtROU9cdAlJKmbwLuVOU/56JhLYu31eF4s6lfp5cH4eKU1oXAt5fDJyaI cOc/cb3qLIAGrHShLFkrNp1+ZqYNFJKuYo9XPyYWuOJU/1fjLB21FrDGaYBqHAaJ S3f3dA4ZKj+r9+L6/vAe6DUPEepN3JX2VIfscCEfOezYbK0+BQM/usPaFcvr56x9 ScUS78phew3gZA6eDafh6s5hBsx4Fc5M4T9lMNsYDVYd13ww0uNlC3GdIGy5OB4w cL83pzHCsi3kGS6UZcAF4W4M3IsmRAQP/USOc/0p8TbpaufSntVtYDIS7E+WvdjK mBsCt/m9qJxfPlFTMD+u2j58BnLee1nH0TLr/cKO/FFaBkbh+Ckgt0KSCRWzJ8xq Xh0jsslzhG9+fRA2YRM1+H1HCXIsDo/UvZkGgGuYSq+5i3E6gpE=
    =zuse
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: you cannot sedate... all the things you hate (1:229/2)