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

  • Bug#1092193: option (or env) to request <=bookworm r-r-r behaviour (2/2

    From Guillem Jover@1:229/2 to Ian Jackson on Tue Jan 7 05:20:01 2025
    [continued from previous message]

    We should probably consider whether we want to make this behaviour controllable by an environment variable, as well. That way a program
    which is trying to work with various different dpkg-buildpackage
    version (eg a CI job that runs with different images) wouldn't have to
    probe for the option.

    As mentioned at the beginning I'm not outright opposed to adding such
    option or environment variable. But TBH I'd like to avoid it if
    possible, because to me it looks deprecated on arrival, and in need
    of an immediate (long-winded) transition to remove it, when external
    packages should be getting switched to use rootless builds. And
    because I guess I don't understand/see the scenario where old packages
    are being used with new tooling, and where the easy scape hatch of
    adding the field with the old behavior value is not a viable solution.

    I was going to say I don't think I understand how this interacts badly
    with dgit, but from your thread with Niels, it looks like dgit might
    need to be changed anyway if it's doing tests based on incorrect
    assumptions, so this part is probably not very relevant anymore?

    Thanks,
    Guillem

    --- SoupGate-Win32 v1.05
    * Origin: you cannot sedate... all the things you hate (1:229/2)
  • From Ian Jackson@1:229/2 to Guillem Jover on Tue Jan 7 11:30:01 2025
    [continued from previous message]

    pernickety and, by their nature, rather fragile. But, it would be
    almost as easy to just change the weird test package.

    So, in summary, please disregard the question of dgit when considering
    this dpkg-buildpackage change request. dgit is not going to pass this
    option. We may abuse it in a few (bizarre) test cases, but that's it.

    I was going to say I don't think I understand how this interacts badly
    with dgit, but from your thread with Niels, it looks like dgit might
    need to be changed anyway if it's doing tests based on incorrect
    assumptions, so this part is probably not very relevant anymore?

    I think the dgit test suite situation is a red herring for this
    discussion. The dgit test suite failure is why I looked at how dpkg-buildpackage was changing.

    But, having looked at how dpkg-buildpackage was changing, I feel we
    are at risk of doing a disservice to downstream users. That is my
    sole motivation here in this bug report.

    It's particularly bad because those downstream users who will suffer
    at the ones least able to cope with the problem. They're the ones who
    are most distant from Debian, with the least knowledge and the fewest
    helpful social connections to Debian experts. (They're already users
    Debian sometimes supports rather poorly.)

    Ideologically, I want *all* computer users everywhere to be able to
    modify the way their computers behave. My goal when working on Debian
    is to help make that possible. That includes users I don't know, and
    it includes distant users who don't have all the relevant information
    and skills and who may have done some broken stuff. We should try to
    make the software we supply easy and forgiving.

    Certainly, we should make our software easy and forgiving when it
    doesn't compromise the quality in other ways.

    I hope this explains my thinking.

    Regards,
    Ian.

    --
    Ian Jackson <[email protected]> These opinions are my own.

    Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
    that is a private address which bypasses my fierce spamfilter.

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