1. Forum
  2. Usenet
  3. LINUX.DEBIAN.MAINT.DPKG

  • Bug#1034710: dpkg-gensymbols: Add higher check level for unnecessary en

    From Andrea Bolognani@1:229/2 to All on Sat Apr 22 12:20:01 2023
    XPost: linux.debian.bugs.dist
    From: eof@kiyuko.org

    Package: dpkg-dev
    Version: 1.21.21
    Severity: wishlist

    When building libvirt, dpkg-gensymbols currently produces the
    following output:

    dpkg-gensymbols: warning: debian/libvirt0/DEBIAN/symbols doesn't match completely debian/libvirt0.symbols
    --- debian/libvirt0.symbols (libvirt0_9.2.0-2_amd64)
    +++ dpkg-gensymbolsFLVUCu 2023-04-22 11:43:15.646242440 +0200
    @@ -1,5 +1,5 @@
    libvirt-admin.so.0 libvirt0 #MINVER#
    - (symver|optional)LIBVIRT_ADMIN_1.3.0 1.2.18
    +#MISSING: 9.2.0-2# (symver|optional)LIBVIRT_ADMIN_1.3.0 1.2.18
    (symver|optional)LIBVIRT_ADMIN_2.0.0 2.0.0~rc1
    (symver|optional)LIBVIRT_ADMIN_3.0.0 3.0.0
    (symver|optional)LIBVIRT_ADMIN_8.6.0 8.9.0

    This is because debian/libvirt0.symbols contains

    libvirt-admin.so.0 libvirt0 #MINVER#
    *@LIBVIRT_ADMIN_1.3.0 1.2.18

    even though no LIBVIRT_ADMIN_1.3.0 symbol was ever added to the
    library.

    It would be nice if such a mistake on the maintainer's part could be
    reported in a way that can't be easily missed or ignored, i.e. a
    build failure. After the maintainer has explicitly opted into this
    behavior by setting DPKG_GENSYMBOLS_CHECK_LEVEL, of course :)

    --
    Andrea Bolognani <eof@kiyuko.org>
    Resistance is futile, you will be garbage collected.

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

    iQIzBAABCgAdFiEEO48t9niVypx3EjLf954fxUKFg6wFAmRDscYACgkQ954fxUKF g6y66xAA2mWR1qVZMYYccdSgPHUy6qHiGeJI/vpcUHnh/Wk5JHpT4Scu346fOJCT kslh9ft/gV3GSkiU430qCop7v6eOLweXwJ2WzqhW6vw9bz2NpWWPk2kxLBqT9AmX swVISameCHT/mGOwgwCtnjBLe15KK0kxAZZa9wUgSrj4LOfZEHlsSImQK2rVl94b 1M86X/KHHxDza50X63Fv8P7CVvuEFzVTtpWP9fP5dE2A7Cxp/+77zoNhlLVf+9Q9 Xm9jjOxPLXXtfpRhYOo5CGplViQqsDOnXpArsgOJdHNU6pFBw1X5TGfUuk5+k7qW 275pZj/QHMu3x3b9VDyFxXMygt3EPcvhJYpH6Wex1rhESzVi1vD+gOhHQI6hhXxn 9Cc+JShm8PqAFWTnHEX7+EJkRuxKOxUnQ5mCcpYyAc7il+/LqPkk+M7zDcgY7bE/ NcvYDgf2FP+3NcmrQJ0BAQhr54LyOJf27syh2eSITQuRF3SWIzZQyj80bZLowmbS 8h09gkpDPGC0svlHlGZWJpZYBGJMi0AEFr3+5nh+pot7AQ0ei/bHSnHZuSc0B6Ck CxDuvongc/N9Upsh0jN3cO9dKSaohVus8Kyoyw8/4aioaT8z/pvNAP+F9EVtYiLK DYgnX5A4M4wZW3FG1WiVdMW1i4ev7XOEdxn9qOPO7yCUrKhMel8=
    =Dcmc
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: you cannot sedate... all the things you
  • From Guillem Jover@1:229/2 to Andrea Bolognani on Fri Jun 9 04:30:01 2023
    XPost: linux.debian.bugs.dist
    From: guillem@debian.org

    Hi!

    On Sat, 2023-04-22 at 12:07:07 +0200, Andrea Bolognani wrote:
    Package: dpkg-dev
    Version: 1.21.21
    Severity: wishlist

    When building libvirt, dpkg-gensymbols currently produces the
    following output:

    dpkg-gensymbols: warning: debian/libvirt0/DEBIAN/symbols doesn't match completely debian/libvirt0.symbols
    --- debian/libvirt0.symbols (libvirt0_9.2.0-2_amd64)
    +++ dpkg-gensymbolsFLVUCu 2023-04-22 11:43:15.646242440 +0200
    @@ -1,5 +1,5 @@
    libvirt-admin.so.0 libvirt0 #MINVER#
    - (symver|optional)LIBVIRT_ADMIN_1.3.0 1.2.18
    +#MISSING: 9.2.0-2# (symver|optional)LIBVIRT_ADMIN_1.3.0 1.2.18
    (symver|optional)LIBVIRT_ADMIN_2.0.0 2.0.0~rc1
    (symver|optional)LIBVIRT_ADMIN_3.0.0 3.0.0
    (symver|optional)LIBVIRT_ADMIN_8.6.0 8.9.0

    This is because debian/libvirt0.symbols contains

    libvirt-admin.so.0 libvirt0 #MINVER#
    *@LIBVIRT_ADMIN_1.3.0 1.2.18

    even though no LIBVIRT_ADMIN_1.3.0 symbol was ever added to the
    library.

    It would be nice if such a mistake on the maintainer's part could be
    reported in a way that can't be easily missed or ignored, i.e. a
    build failure. After the maintainer has explicitly opted into this
    behavior by setting DPKG_GENSYMBOLS_CHECK_LEVEL, of course :)

    I think this is a good idea, and I'm planning on implementing it. The
    problem is that I don't know for example in Debian how many packages
    might FTBFS due to this. So off-hand adding this as part of an
    existing check level might be problematic. Adding it as a higher level
    would imply requiring more checks than the ones the maintainer might
    want to handle, so that does not look like a nice option, even if it
    would be the safest one. I guess if the check selection had been
    implemented as an union of strings instead of integer levels, it would
    be more extensible.

    Thanks,
    Guillem

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