Bug#1019409: Bug#993161: pam: some remaining changes for DPKG_ROOT

[Steve Langasek]

On Wed, Oct 05, 2022 at 02:13:16PM +0200, Johannes Schauer Marin Rodrigues 
wrote:
> Hi Steve,

> Quoting Steve Langasek (2022-09-09 07:09:32)
> > My feedback to you on IRC was that I think it's inappropriate for you to go
> > package-by-package in the BTS to the packages in the base set expecting
> > support for a feature that has to my knowledge never been surfaced for
> > project-wide discussion on debian-devel or similar.

> > So if you want to take that discussion to the Technical Committee to ratify
> > as something that base packages must support, well, I don't think that's the
> > best use of the TC vs just starting a thread on debian-devel,

> I agree that this is not the best use of the TC's time. Since we both agree on
> that and since it has been more than three weeks since our post to d-devel [1]
> without any concerns or otherwise negative feedback, do you still want to wait
> for the TC to decide or do you want to cut it short by applying our patch?

> [1] https://lists.debian.org/166289720850.2390.3729551131862514967@localhost

No need to wait on the TC at all; your post and the subsequent discussion on
debian-devel (and -policy) addresses my concerns, thank you.  At this point
committing and uploading is blocked only on me having the time to context
switch, review the diff (because I deeply trust Sam's technical judgement,
nevertheless won't commit/upload something in my own name without looking at
it myself for accountability purposes), and upload.  I hope I might get this
done this week.

> > but it does satisfy my expectation that there be a project-level review of
> > the design prior to obligating base package maintainers to support this
> > feature.

> We are working on some changes to Debian policy in #1020323 but we are not
> planning to put any "must" statements in the text. Our intention is not to
> obligate anybody to do anything other than apply reasonable patches that we
> provide. If it breaks, it is not your responsibility to fix it. Since the
> DPKG_ROOT variable is empty during normal installations I hope you agree that
> our patch will not be able to introduce any bugs during normal package
> installation. If the chrootless bootstrapping should fail in the future, it is
> not the obligation of package maintainers to fix it. We have said so multiple
> times in the past already...

Hmm, possibly paralleling some other discussions elsewhere.  I understand
and appreciate your position that you will do the work to fix any bugs in
this feature.  As a maintainer, I am happy to work with you on this.  I
don't mean obligation in a policy sense, there was clearly no Debian Policy
language around this at all at the time!  I mean it in a more general sense
encompassing both "social expectations of a fellow maintainer to cooperate"
and "decision imposed by the TC".

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#1019409: Bug#993161: pam: some remaining changes for DPKG_ROOT

[Johannes Schauer Marin Rodrigues]

Hi Steve,

Quoting Steve Langasek (2022-09-09 07:09:32)
> My feedback to you on IRC was that I think it's inappropriate for you to go
> package-by-package in the BTS to the packages in the base set expecting
> support for a feature that has to my knowledge never been surfaced for
> project-wide discussion on debian-devel or similar.
> 
> So if you want to take that discussion to the Technical Committee to ratify
> as something that base packages must support, well, I don't think that's the
> best use of the TC vs just starting a thread on debian-devel,

I agree that this is not the best use of the TC's time. Since we both agree on
that and since it has been more than three weeks since our post to d-devel [1]
without any concerns or otherwise negative feedback, do you still want to wait
for the TC to decide or do you want to cut it short by applying our patch?

[1] https://lists.debian.org/166289720850.2390.3729551131862514967@localhost

> but it does satisfy my expectation that there be a project-level review of
> the design prior to obligating base package maintainers to support this
> feature.

We are working on some changes to Debian policy in #1020323 but we are not
planning to put any "must" statements in the text. Our intention is not to
obligate anybody to do anything other than apply reasonable patches that we
provide. If it breaks, it is not your responsibility to fix it. Since the
DPKG_ROOT variable is empty during normal installations I hope you agree that
our patch will not be able to introduce any bugs during normal package
installation. If the chrootless bootstrapping should fail in the future, it is
not the obligation of package maintainers to fix it. We have said so multiple
times in the past already...

josch

signature.asc
Description: signature

Bug#1019409: Bug#993161: pam: some remaining changes for DPKG_ROOT

[Sean Whitton]

Hello,

On Sun 18 Sep 2022 at 03:11PM +02, Helmut Grohne wrote:

> Hi,
>
> On Sat, Sep 10, 2022 at 11:57:48PM +0200, Johannes Schauer Marin Rodrigues 
> wrote:
>> From my side, I'd be fine with the TC pausing any action on this issue and
>> waiting for our mail to d-devel first. This is assuming that if there is no
>> opposition to the DPKG_ROOT idea, that Steve then also has no objection 
>> against
>> merging our patch.
>>
>> Helmut, what do you think?
>
> I think that the CTTE is so slow that there is no need to pause in any
> way. The d-devel thread seems rather boring, so we may as well move
> ahead.
>
> Let me restate that I see this as a procedural issue. I believe that a
> maintainer has an obligation to communicate in a reasonable way. For
> instance, we file RC bugs when the maintainer address bounces. I argue
> that maintainer communication isn't working for pam. Even if more
> arguments against DPKG_ROOT pop up now, I kinda find it late on
> procedural grounds.
>
> So no, let's not pause this. Nothing has changed really. While Steve did
> reply, that doesn't happen to please Sam. If the three weeks expired
> today, I would have referred it to the CTTE as well.

You'll have seen it, but for the benefit of others, at our meeting this
week we decided that we will review the patch and determine whether we
have a consensus about applying it during our next monthly meeting.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1019409: Bug#993161: pam: some remaining changes for DPKG_ROOT

[Helmut Grohne]

Hi,

On Sat, Sep 10, 2022 at 11:57:48PM +0200, Johannes Schauer Marin Rodrigues 
wrote:
> From my side, I'd be fine with the TC pausing any action on this issue and
> waiting for our mail to d-devel first. This is assuming that if there is no
> opposition to the DPKG_ROOT idea, that Steve then also has no objection 
> against
> merging our patch.
> 
> Helmut, what do you think?

I think that the CTTE is so slow that there is no need to pause in any
way. The d-devel thread seems rather boring, so we may as well move
ahead.

Let me restate that I see this as a procedural issue. I believe that a
maintainer has an obligation to communicate in a reasonable way. For
instance, we file RC bugs when the maintainer address bounces. I argue
that maintainer communication isn't working for pam. Even if more
arguments against DPKG_ROOT pop up now, I kinda find it late on
procedural grounds.

So no, let's not pause this. Nothing has changed really. While Steve did
reply, that doesn't happen to please Sam. If the three weeks expired
today, I would have referred it to the CTTE as well.

Helmut

Bug#1019409: Bug#993161: pam: some remaining changes for DPKG_ROOT

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Steve Langasek (2022-09-10 22:16:55)
> > > > For the record I do not consider this an override requiring a
> > > > supermajority and would abide by a majority TC decision.
> 
> > > Thank you for your input.  The TC can just issue advice after reviewing
> > > the proposed changes, in this case.  An alternative would be to word the
> > > resolution such that it counts as advice if we have a simple majority
> > > and an override if we have a supermajority.  I'd prefer the former, but
> > > it would be good to hear from Helmut about it.
> 
> > AIUI, Steve's objection is substantially that this is quite an invasive
> > change to make across our toolchain, and should be discussed on debian-devel
> > before just being implemented package-by-package (rather than any particular
> > objection to the approach). Is that correct?
> 
> I think that's a fair characterization, yes.
> 
> I support the goal of making it easier to bootstrap ports.  I also don't
> even see a cleaner way to accomplish this than what's proposed.  But I think
> there's a duty, when making distro-level changes, to have a project-level
> discussion about what's being proposed and why, and to get consensus on it,
> not just file a bunch of bug reports on individual packages.

I think there's a duty, when maintaining a package, to at least send a short
reply to bugs against your package and even more so, if pinged multiple times
and your co-maintainer explicitly waiting for you and thus this non-action
resulting in blocking other people's work. We invoked the TC not because we did
not want to discuss on d-devel but because you have kept silent since February
2021 when we filed our initial bug #983427 against pam.  In hindsight, we
should've written to d-devel, yes.  Helmut and myself are working on a mail to
send to d-devel to get this done now in the sense of "better late than never".
We didn't think that such a mail was necessary because there are only 10 source
packages (including pam) that require the DPKG_ROOT variable in their
maintainer script for this mechanism to work (that's why I wouldn't classify
this as "distro-level change") and because the required changes to maintainer
scripts result in zero behaviour changes on anything that is not
early-bootstrap.

>From my side, I'd be fine with the TC pausing any action on this issue and
waiting for our mail to d-devel first. This is assuming that if there is no
opposition to the DPKG_ROOT idea, that Steve then also has no objection against
merging our patch.

Helmut, what do you think?

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1019409: Bug#993161: pam: some remaining changes for DPKG_ROOT

[Steve Langasek]

On Sat, Sep 10, 2022 at 05:36:13PM +0100, Matthew Vernon wrote:
> On 09/09/2022 19:45, Sean Whitton wrote:
> > Hello,

> > On Thu 08 Sep 2022 at 10:09PM -07, Steve Langasek wrote:

> > > For the record I do not consider this an override requiring a
> > > supermajority and would abide by a majority TC decision.

> > Thank you for your input.  The TC can just issue advice after reviewing
> > the proposed changes, in this case.  An alternative would be to word the
> > resolution such that it counts as advice if we have a simple majority
> > and an override if we have a supermajority.  I'd prefer the former, but
> > it would be good to hear from Helmut about it.

> AIUI, Steve's objection is substantially that this is quite an invasive
> change to make across our toolchain, and should be discussed on debian-devel
> before just being implemented package-by-package (rather than any particular
> objection to the approach). Is that correct?

I think that's a fair characterization, yes.

I support the goal of making it easier to bootstrap ports.  I also don't
even see a cleaner way to accomplish this than what's proposed.  But I think
there's a duty, when making distro-level changes, to have a project-level
discussion about what's being proposed and why, and to get consensus on it,
not just file a bunch of bug reports on individual packages.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#1019409: Bug#993161: pam: some remaining changes for DPKG_ROOT

[Matthew Vernon]

On 09/09/2022 19:45, Sean Whitton wrote:

Hello,

On Thu 08 Sep 2022 at 10:09PM -07, Steve Langasek wrote:


For the record I do not consider this an override requiring a
supermajority and would abide by a majority TC decision.


Thank you for your input.  The TC can just issue advice after reviewing
the proposed changes, in this case.  An alternative would be to word the
resolution such that it counts as advice if we have a simple majority
and an override if we have a supermajority.  I'd prefer the former, but
it would be good to hear from Helmut about it.


AIUI, Steve's objection is substantially that this is quite an invasive 
change to make across our toolchain, and should be discussed on 
debian-devel before just being implemented package-by-package (rather 
than any particular objection to the approach). Is that correct?


But that Sam is unsold on the technical approach and wanted input from 
Steve before agreeing?


Regards,

Matthew

Bug#1019409: Bug#993161: pam: some remaining changes for DPKG_ROOT

[Sean Whitton]

Hello,

On Thu 08 Sep 2022 at 10:09PM -07, Steve Langasek wrote:

> For the record I do not consider this an override requiring a
> supermajority and would abide by a majority TC decision.

Thank you for your input.  The TC can just issue advice after reviewing
the proposed changes, in this case.  An alternative would be to word the
resolution such that it counts as advice if we have a simple majority
and an override if we have a supermajority.  I'd prefer the former, but
it would be good to hear from Helmut about it.

-- 
Sean Whitton

Bug#1019409: Bug#993161: pam: some remaining changes for DPKG_ROOT

[Steve Langasek]

On Thu, Sep 08, 2022 at 09:51:41PM +0200, Helmut Grohne wrote:
> Hi technical comittee members,

> On Thu, Aug 18, 2022 at 03:44:54PM +0200, Helmut Grohne wrote:
> > Within three weeks I want Steve to reply to this bug in a way that
> > addresses Sam's needs or Sam to agree with moving forward without
> > Steve's review. Failing that, I will ask the CTTE to override the pam
> > maintainers on this patch.

> I hope that it does not surprise you. I am formally asking the CTTE to
> override the pam maintainers and requiring pam to support DPKG_ROOT.

My feedback to you on IRC was that I think it's inappropriate for you to go
package-by-package in the BTS to the packages in the base set expecting
support for a feature that has to my knowledge never been surfaced for
project-wide discussion on debian-devel or similar.

So if you want to take that discussion to the Technical Committee to ratify
as something that base packages must support, well, I don't think that's the
best use of the TC vs just starting a thread on debian-devel, but it does
satisfy my expectation that there be a project-level review of the design
prior to obligating base package maintainers to support this feature.

> (e.g. quality assurance, limitation of scope, public discussion at DC22,
> etc.)

I did not attend DC22 and this is literally the first time I've heard that
there was going to be a session about this.  I'm glad that this is getting
wider socialization within the project, but without knowing who was present
for the discussion, how widely the session was disseminated ahead of time,
and what kind of feedback was given, I don't think this rises to the level
of a project-reviewed agreement.

Looking at the list of videos from DebConf 22

  

I find the session entitled "What is DPKG_ROOT?"

  


which is good, but also appears to be a rather small self-selecting
audience.

>  * pam should support DPKG_ROOT and accept reasonable changes to that
>end.
>  * In particular, the patch in bug #993161 is considered a reasonable
>change with bearable maintenance cost and thus should be included
>in pam.

> Since I am requesting a maintainer override, a super majority is
> required.

For the record I do not consider this an override requiring a
supermajority and would abide by a majority TC decision.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature