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

  • Bug#1036865: dpkg-dev: Overreaching Rules-Requires-Root namespace check

    From Niels Thykier@1:229/2 to All on Sun May 28 10:50:01 2023
    XPost: linux.debian.bugs.dist
    From: niels@thykier.net

    Package: dpkg
    Version: 1.21.22
    Severity: minor
    X-Debbugs-Cc: niels@thykier.net


    I was playing around with doing a custom name space for
    Rules-Requires-Root, and then dpkg said it owned the namespace:

    ```
    $ grep Rules-Requires-Root debian/control
    Rules-Requires-Root: debputy/deb-assembly
    $ dpkg-buildpackage -us -uc -nc -B -Pnoudeb
    dpkg-buildpackage: error: Rules-Requires-Root field keyword "debputy/deb-assembly" is unknown in dpkg namespace
    ```

    Personally, I was a bit surprised because I did not feel like dpkg has a
    claim on this namespace. It turns out that dpkg currently believes it
    owns *all* namespaces:

    ```
    $ grep Rules-Requires-Root debian/control
    Rules-Requires-Root: foo/bar
    $ dpkg-buildpackage -us -uc -nc -B -Pnoudeb
    dpkg-buildpackage: error: Rules-Requires-Root field keyword "foo/bar" is unknown in dpkg namespace
    ```

    Please review the namespace check. Behaviour-wise there is a bug in it somewhere.

    Best regards,
    Niels

    --- SoupGate-Win32 v1.05
    * Origin: you cannot sedate... all the things you hate (1:229/2)
  • From Guillem Jover@1:229/2 to Niels Thykier on Sun May 28 12:20:01 2023
    XPost: linux.debian.bugs.dist
    From: guillem@debian.org

    Hi!

    On Sun, 2023-05-28 at 10:26:46 +0200, Niels Thykier wrote:
    Package: dpkg
    Version: 1.21.22
    Severity: minor
    X-Debbugs-Cc: niels@thykier.net

    I was playing around with doing a custom name space for Rules-Requires-Root, and then dpkg said it owned the namespace:

    ```
    $ grep Rules-Requires-Root debian/control
    Rules-Requires-Root: debputy/deb-assembly
    $ dpkg-buildpackage -us -uc -nc -B -Pnoudeb
    dpkg-buildpackage: error: Rules-Requires-Root field keyword "debputy/deb-assembly" is unknown in dpkg namespace
    ```

    Personally, I was a bit surprised because I did not feel like dpkg has a claim on this namespace. It turns out that dpkg currently believes it owns *all* namespaces:

    ```
    $ grep Rules-Requires-Root debian/control
    Rules-Requires-Root: foo/bar
    $ dpkg-buildpackage -us -uc -nc -B -Pnoudeb
    dpkg-buildpackage: error: Rules-Requires-Root field keyword "foo/bar" is unknown in dpkg namespace
    ```

    Please review the namespace check. Behaviour-wise there is a bug in it somewhere.

    Ugh, so from code staring and git log, it seems this has not worked since
    the code got added. Which should also mean the debhelper namespace which
    is documented in the spec does not work either. :/

    I've prepared the attached patch which I think should be fixing this,
    but will test and add some functional tests to check for this to make
    sure and avoid regressions.

    I might look into whether to target stable releases too given that
    it's a small fix (although no one else reported this until now, but
    that might only mean people thought this was allowed…).

    Thanks,
    Guillem

    diff --git i/scripts/dpkg-buildpackage.pl w/scripts/dpkg-buildpackage.pl
    index bf43fb5cf..f119f11f5 100755
    --- i/scripts/dpkg-buildpackage.pl
    +++ w/scripts/dpkg-buildpackage.pl
    @@ -846,7 +846,7 @@ sub parse_rules_requires_root {
    if ($keyword =~ m{^dpkg/target/(.*)$}p and $target_official{$1}) {
    error(g_('disallowed target in %s field keyword "%s"'),
    'Rules-Requires-Root', $keyword);
    - } elsif ($keyword ne 'dpkg/target-subcommand') {
    + } elsif ($keyword =~ m{^dpkg/(.*)$} and $1 ne 'target-subcommand') {
    error(g_('%s field keyword "%s" is unknown in dpkg namespace'),
    'Rules-Requires-Root', $keyword);
    }

    --- SoupGate-Win32 v1.05
    * Origin: you cannot sedate... all the things you hate (1:229/2)
  • From Niels Thykier@1:229/2 to All on Sun Jun 18 11:40:01 2023
    XPost: linux.debian.bugs.dist
    From: niels@thykier.net

    Guillem Jover:
    Hi!


    Hi,

    [...]

    Ugh, so from code staring and git log, it seems this has not worked since
    the code got added. Which should also mean the debhelper namespace which
    is documented in the spec does not work either. :/


    I pulled out the debhelper keyword, so currently the debhelper namespace
    would be empty. I do not remember what we wrote in the spec. If it
    lists a concrete debhelper keyword, then I feel that is a bug in the
    example from the spec (as the keyword is not supported).

    I've prepared the attached patch which I think should be fixing this,
    but will test and add some functional tests to check for this to make
    sure and avoid regressions.


    LGTM without having tested it.

    I might look into whether to target stable releases too given that
    it's a small fix (although no one else reported this until now, but
    that might only mean people thought this was allowed…).

    Thanks,
    Guillem

    I think no body has had a reason for using a non-dpkg namespaced keyword
    up till now. I retracted the debhelper one because it does not work well
    in practice. I only discovered this because I wanted to introduce a R³
    for debputy, where I feel it the usage would work in practice.

    For the record, I have added said R³ keyword in debputy for the next
    release with a reference to this bug. I doubt it will create a lot of
    noise in the short term given debputy is "experimental-only" right now.
    It would have to be in a stable-backport before a stable update to dpkg
    would matter.
    And even then, the work around is for debputy to fallback to its
    internal assembly method or have the package degrade to "R³:
    binary-targets".

    Best regards,
    Niels

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