• Re: Bug#994388: dpkg currently warning about merged-usr systems

    From Wouter Verhelst@21:1/5 to Josh Triplett on Fri Apr 8 09:40:01 2022
    Hi,

    On Tue, Mar 15, 2022 at 03:14:36PM -0700, Josh Triplett wrote:
    It would appear that the situation has deteriorated further. dpkg 1.21.2
    now issues a warning on all merged-usr systems:

    Setting up dpkg (1.21.2) ...
    dpkg: warning: System unsupported due to merged-usr-via-aliased-dirs.
    dpkg: warning: See <https://wiki.debian.org/Teams/Dpkg/FAQ#broken-usrmerge>.

    This escalation seems in direct contradiction to the tech-ctte decision
    in 994388. Moreover, this seems to effectively use package maintainer
    scripts as a means of directing a complaint at Debian users that has not gotten traction in other forums, and then directing such users at a wiki
    page that contradicts a prior project decision.

    This does not even seem to be calling for help in any meaningful way.
    For instance, soliciting help updating dpkg to handle such
    configurations might have been more productive; that still wouldn't be appropriate in a maintainer script, but it might have been productive in
    a mail to -devel. But this isn't soliciting help, it's just incorrectly declaring the user's system broken.

    This seems counterproductive and harmful.

    FWIW, I think the TC should punt this bug to a GR.

    The dpkg maintainer has chosen not to engage with the TC in #994388, and
    now seems to be actively subverting a validly-made TC decision.

    I do believe it reasonable to assume the dpkg maintainer has a point if
    he believes that the currently-chosen way of moving forward is harmful. However, the right way for him to make that point would have been to
    engage with the TC, the body constitutionally placed to resolve
    conflicts of this manner, not ignoring them and then doing whatever he
    wants when the decision inevitably doesn't go his way.

    I encourage the dpkg maintainer (Cc'd) to engage with the TC in this
    matter. It is not yet too late; the TC can always roll back decisions it
    made earlier if it believes, in light of new arguments, those decisions
    to be wrong. However, if this does not happen, then that does not
    inspire me with confidence that whatever the TC decides after weighing
    all the arguments available to them, the dpkg maintainer will follow
    that ruling. Given that, in case the dpkg maintainer chooses to remain
    silent again, I believe the only way forward is for the TC to recommend
    a GR under §4.2.1 of the consitution.

    --
    w@uter.{be,co.za}
    wouter@{grep.be,fosdem.org,debian.org}

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Wouter Verhelst@21:1/5 to Wookey on Fri Apr 8 16:50:01 2022
    On Fri, Apr 08, 2022 at 02:31:27PM +0100, Wookey wrote:
    On 2022-04-08 09:36 +0200, Wouter Verhelst wrote:

    The dpkg maintainer has chosen not to engage with the TC in #994388, and now seems to be actively subverting a validly-made TC decision.

    I do believe it reasonable to assume the dpkg maintainer has a point if
    he believes that the currently-chosen way of moving forward is harmful. However, the right way for him to make that point would have been to
    engage with the TC, the body constitutionally placed to resolve
    conflicts of this manner, not ignoring them and then doing whatever he wants when the decision inevitably doesn't go his way.

    I encourage the dpkg maintainer (Cc'd) to engage with the TC in this matter. It is not yet too late;

    That all sounds reasonable, but there is the long-standing issue that
    Guillem has never accepted that the TC has authority over the
    project. I forget the details, but given that he does not see it as
    valid it's not surprising that he is not engaging with it.

    Why does that matter? I honestly don't care.

    Debian has a set of rules. It's called our "constitution". We all follow
    those rules when we engage with the project, for instance when we are
    voting.

    wouter@pc181009:~/debian/webwml/english/vote$ grep 'guillem' */*voters.txt|wc -l
    42

    You don't get to exercise your rights in our constitution in one
    instance but ignore your duties in another. The constitution exists, and
    it is not an optional document. Either you agree by it (and then you get
    to vote, etc), or you don't (and then what are you doing here). If one
    party can get their way simply by ignoring the rules, then we might as
    well pack up and forget this whole Debian thing even happened in the
    first place.

    There have been cases in the past where Debian has made decisions that I disagreed with. There have been cases where I seriously considered
    leaving the project. In the end, I chose not to do so, in part because
    the rules we follow made the decision a fair one, even if I did not
    agree with it.

    For clarity, and again, I am inclined to agree with the dpkg maintainer
    on the matter of how the /usr merge should be implemented; but I am
    seriously offended by how he is acting in this manner. This is not how
    things should be done.

    --
    w@uter.{be,co.za}
    wouter@{grep.be,fosdem.org,debian.org}

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Guillem Jover@21:1/5 to Wouter Verhelst on Fri Apr 8 18:50:01 2022
    Hi Wouter,

    On Fri, 2022-04-08 at 09:36:21 +0200, Wouter Verhelst wrote:
    FWIW, I think the TC should punt this bug to a GR.

    I don't think deciding technical matters via GR is a great idea…
    but I guess it's a good opportunity for some people to put on the
    table getting rid of the "dpkg maintainer" (not talking about you). :/

    The dpkg maintainer has chosen not to engage with the TC in #994388,

    I think I've made my position regarding the TC public for a long time. Recentish summaries:

    <https://lists.debian.org/debian-devel/2016/11/msg00458.html>
    <https://lists.debian.org/debian-ctte/2018/07/msg00021.html>
    <https://lists.debian.org/debian-policy/2019/07/msg00092.html>

    I don't think I've "engaged" with the TC since around 2013. I do of
    course recognize its authority, even though as stated above I think
    it's an awful way to resolve issues.

    and now seems to be actively subverting a validly-made TC decision.

    Hmm, this characterization of my supposed motivations and objectives,
    seems unfair, so I'll try to explain my train of thought below:

    (Also I'm assuming we are talking about the warning that has since been silenced in Debian, for a week now.)

    - There's been already a notice/warning in the dpkg's reportbug bugscript
    for a long time now.

    - I'm of the opinion that dpkg users (in Debian and elsewhere) deserve
    to know whether dpkg will be able to operate correctly on *their*
    system.

    - The warning was added via dpkg's postinst, which gets emitted only
    during installation/upgrade, which to me meant, less technical inclined
    users which might not be able to evaluate it are not going to see it
    from a GUI or similar, and that even on oldstable to stable upgrades,
    it would probably be missed due to being drowned on all the other
    output text. So I honestly do not expect it will have a great impact
    on such upgrades anyway.

    - In Debian, most of the breakage in dpkg _might_ be externally detected
    and prevented by QA tools, as long as the users would not use external
    repos, backports, or old .debs say from snapshots, or directly interface
    with dpkg tools, which seemed would apply in most cases to GUI users
    that would not see the warning at all anyway.

    - The TC ruling stated that Debian supports for now both layouts, while
    dpkg does not and has never supported the merged-usr-via-aliased-dirs
    one, and given that Debian is not supposed to leave people behind or
    require them to reinstall in case they are not yet using
    merged-usr-via-aliased-dirs, it seemed fair to me to let people decide
    about these potential current trade-offs by themselves (and
    definitely not to use them as a mob to pressure or attack anyone
    with!).

    - I've mentioned this in the past already, and even if I now suddenly
    found the motivation with the previous and current climate, to add
    proper support for this into dpkg, only adding the foundation and
    being able to use it might take from one to two Debian release
    cycles anyway:

    <https://lists.debian.org/debian-devel/2021/08/msg00363.html>
    <https://lists.debian.org/debian-devel/2021/08/msg00103.html>

    and that does not include actual proper support for the thing.

    - You talk about (ab)using power, but I _think_ I'm pretty careful and
    mindful about the responsibility that comes with being upstream and
    maintaining packages. In the end I think this could be mischaracterized
    about any upstream or maintainer, TBH :/. If I had wanted to "abuse
    power" (something that has never even crossed my mind doing as such,
    as I think it would have been completely inappropriate), I could have
    say Conflicted on usrmerge (which while I've always thought it was
    producing fsys layouts unsupported by dpkg, the users should be
    obviously free to do with their system as they please), or say even
    try to run dpkg-fsys-usrunmess (which on the same note, is something
    that I cannot decide on behalf of the users).

    - If I had known that people in Debian would get this offended about a
    factual warning to the point of picking up the pitch forks, with the
    subsequent actions which I perceive as bullying with calls for
    expulsions, DM demotions, upload privs removals, etc, etc. I'd probably
    have still added the warning but directly silenced for Debian, because
    life's too short, yes.

    - The warning did not intend to claim that Debian did or did not support
    anything. I thought it was obvious this being a dpkg warning, it
    implied it was stating what dpkg supports or not. Also didn't want to
    drown the screen with text, so initially went for a fairly short note.
    This seemed to confuse people, so I updated it to try to make it
    clearer, and expanded it a bit. Before silencing it on Debian, as per
    the above.

    - dpkg is used way beyond Debian, and its own maintscripts are shared
    by any distribution making use of them. I've actually been pondering
    for a long while to make the dpkg tool suite non-native, to perhaps
    make this all more clear.


    So, given the above, my intention was not to try to subvert or work
    against that TC decision. But reading now your statement and someone
    else mentioning the Debian Constitution $2.1.1, I guess I can see how
    some people could perceive it like that, and I'm truly sorry about
    that. :/ The reactions have been shoot first, ask later (if at all),
    which also seemed dismaying to me, of course communication around
    merged-/usr have not been working in Debian at all for years now…

    :(,
    Guillem

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)