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

Bug#993161: pam: some remaining changes for DPKG_ROOT

[Helmut Grohne]

Control: clone -1 -2
Control: retitle -2 decide whether pam should support DPKG_ROOT
Control: tags -2 =
Control: reassign -2 tech-ctte

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.

DPKG_ROOT is a feature that allows installing packages into a chroot
without using the chroot syscall. The major benefit of doing so is
creating foreign chroots without requiring qemu for emulating maintainer
scripts. To work in such a setting, relevant maintainer scripts need to
be modified to operate on a chroot from outside. The location of the
chroot is communicated by dpkg using the DPKG_ROOT environment variable.
This feature is relevant to early architecture bootstrap where qemu is
not reliably available. As such the package set covered initially is
essential (thus covering pam) and shall be extended to build-essential.
Patches have been sent to all relevant essential packages and have been
applied by most. pam already carries partial support for DPKG_ROOT due
to Sam Hartman applying an earlier patch. Thank you. Unfortunately, we
later noticed that it was incomplete when we extended our QA and sent a
followup patch. This second patch is being pending in pam for about a
year. During that year, Sam repeatedly expressed discomfort with how we
approached the problem. In the end, Sam requested Steve to comment on
the matter. However, Steve has not participated at all. As such, the
patch is not being applied and eternally waiting for Steve (no pun
intended). We believe that we addressed all concerns (e.g. quality
assurance, limitation of scope, public discussion at DC22, etc.) raised
by Sam. Yet progress repeatedly stalled on this matter. Please read the
bug log for details. I've come to the conclusion that I will be unable
to resolve this.  Therefore, I ask the CTTE to override the pam
maintainers:

 * 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.
 * pam maintainers are in no way required to support DPKG_ROOT beyond
   accepting reasonable patches and communicating in a timely manner.
   Keeping DPKG_ROOT in a working state is the sole responsibility of
   its proponents.

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

Helmut

Bug#993161: pam: some remaining changes for DPKG_ROOT

[Helmut Grohne]

Hi Sam and Steve,

On Sun, Jan 23, 2022 at 02:22:53PM +0100, Helmut Grohne wrote:
> In any case, as long as we are actively discussing the technical means,
> we have no intention to push for a rapid inclusion. To the contrary:
> Please wait with applying the proposed changes as long as the discussion
> progresses.

It seems to me that the discussion no longer progresses.

On a very high level, it seems to me that we cannot move forward with
this change, because Sam wants the input of Steve first and Steve does
not reply at all. However, Steve just managed to upload pam, so he does
something to the package. That seems strange to me at the very least.

In essence, we have an unresolvable conflict between three parties. We
want a patch included. Sam doesn't want the patch included without
Steve's input. Steve doesn't want to give input. The natural route to
solve such conflicts is the CTTE. I think Josch and myself have put up
with a lot of patience. Basically, we've tried every constructive
approach we could think of (including having a jitsi session with Sam).
In that process, we've adapted the scope of our feature request due to
input from Sam. We've let this take so long, because every time Sam
replied, he was being constructive except for the fact that he blocked
inclusion on input from Steve. Let's try with a deadline:

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.

Disclaimer: In the event that the CTTE has to rule on this, I will not
cast a vote myself.

Helmut

Bug#993161: pam: some remaining changes for DPKG_ROOT

[Helmut Grohne]

Hi Sam,

I'm very glad about your mail.

On Wed, Jan 19, 2022 at 05:57:15PM -0700, Sam Hartman wrote:
> [Feel free to quote in public with attribution.
> I'm sending privately to allow you to control distribution.]

Thank you for your trust in me. I think that your mail is mostly
technical and contains a few personal aspects. While I'm glad for those
words on a personal level, I don't think they help in the public
discussion. Therefore, I've left them out in what mostly is a
full-quote. Please let me know if you disagree with the selection.

Thus, this reply goes to the bug report to continue in a public spot.

> Hi.  I've owed you an explanation on this for a while not, and I regret
> that I allowed other less enjoyable (and less technical) aspects of
> Debian to dominate my thoughts.

Thank you!

> We had a call where we talked about  DPKG_ROOT.
> There were two use cases.
> 
> 1) architectures without qemu.
> You sold me on the importance of this use case.

Good.

> 2) Being able to build for embedded systems without root.
> Putting it mildly I remain unconvinced on this use case.

I think it was actually the other way round. You sold us on this not
being a relevant problem to solve. Since bullseye, user namespaces are
widely available and effectively that is the far easier tool for this
problem.

However, there is one nuance to this that may come back in future. When
building embedded systems, we want their rootfs to be small. Kicking out
everything that we do not need is key. Often times that includes the
dpkg database and the maintainer scripts. Thus it would - in theory - be
feasible to remove anything that is only required by maintainer scripts.
At present, we have no way of telling apart which dependencies are
required for maintainer scripts and which are required for using the
package. Those two concepts are not separated in any way. However, we
have been talking about separating them for at least three years. Think
of this as an early draft for a proposal, not something set in stone.
The takeaway roughly is that if we manage to split package dependencies
into two categories for installation and for runtime, then DPKG_ROOT
poses another gain as those installation dependencies can be removed
from the system that is to be bootstrapped. Please consider this a weak
argument at least for now. You can easily construct counter arguments:
We might install those dependencies inside and remove them at the end.
The reason I'm including it here is to avoid an unpleasant surprise
later on.

> To understand my thoughts, I'd like to describe a bit how I see Debian
> and the maintainer scripts.

I find your way of approaching this very good. I keep learning from you
in terms of how to constructively discuss things. As we'll see, this
bottom-up approach makes it easy to figure out where exactly we
disagree rather than build on inconsistent assumptions.

> We adopted a fairly simple model for maintainer scripts: they run as
> root on the installed system.
> This has huge advantages: it's allowed us to package a lot of software.
> It's easy to reason about.

People have radically differing opinions on that last point. For
instance, Ralf Treinen is involved with CoLiS, a framework for reasoning
about maintainer scripts and if you ask him, "easy" is likely one of the
things he wouldn't attribute. Often times, we only reason about them in
terms of trying whether they work in practice. For that reason, a number
of people are looking for ways to eliminate them in places where we can
do without. You can see dpkg triggers as a way of making them more
declarative. Guillem Jover and Niels Thykier have invested quite some
time into maintainer script removal. Examples include:
 * https://wiki.debian.org/Teams/Dpkg/Spec/MetadataTracking
 * https://wiki.debian.org/Teams/Dpkg/Spec/DeclarativePackaging
A big chunk of the work Johannes and myself invested into DPKG_ROOT was
eliminating unnecessary maintainer scripts.

Can we agree on "easy to reason about" being very subjective? That
really depends on how you look at it.

When it comes to consensus, my perception is that the majority of people
I talk to is in favour of declarative approaches. This applies to
metadata (i.e. what fakeroot solves) in particular.

> We adopted a similar model for builds.
> Many other packaging systems adopted complex models for setting file
> permissions and the like.
> We decided we'd use fakeroot--we captured and modified the OS in order
> to extract the information we needed from the install process and to
> allow people to use familiar tools.
> It worked so much better than other similar systems of the mid 1990's.

Again, this does have two sides. Most of the time, it just works.
fakeroot breaks every so often. It plays whack-a-mole with an ever
evolving glibc and linux. Johannes even had to NMU it once. Worse, we
also have pseudo, which provides fakeroot. I've recently lost more than
an hour figuring out why tar would segfault during a python2.7 

Bug#993161: pam: some remaining changes for DPKG_ROOT

[Johannes Schauer Marin Rodrigues]

Hi Sam,

Quoting Sam Hartman (2022-01-18 01:28:50)
> > "Johannes" == Johannes Schauer Marin Rodrigues  
> > writes:
> 
> Johannes> Hi Steve, Quoting Johannes Schauer Marin Rodrigues
> Johannes> (2021-12-08 10:00:31)
> Johannes> Since it has been more than a month without any reply I
> Johannes> just uploaded a NMU of pam with the attached debdiff to
> Johannes> DELAYED/10.  Those are the same changes as from
> Johannes> https://salsa.debian.org/vorlon/pam/-/merge_requests/7 and
> Johannes> our CI passes with those changes to pam
> Johannes> https://salsa.debian.org/helmutg/dpkg-root-demo/-/jobs
> 
> I have attempted to cancel this NMU.

I've done the same right now to make sure it's cancelled.

> I've tried to explicitly nack this change without feedback from Steve,
> and I stand behind this.
> This change adds a maintenance burden that I'm not entirely comfortable
> accepting either as an NMU or as a co-maintainer without full authority.
> 
> I'm guessing my previous statement on this was insufficiently clear.
> Please wait for feedback from Steve before integrating this change.

I understand that you are worried about the added maintenance burden. But I
also offered to help you with any problems that should arise from this change.

Can I offer you a trade? I see that the list of lintian issues for src:pam is
extremely long. The debhelper version used by pam is deprecated and the
standards version is four years old. I'd offer you to put in a few hours of my
time to modernize the pam packaging and thus spend some maintenance time on
src:pam so that you or Steve don't have to do that. Thus, you save some of your
time which in the future you can spend on writing me an email in case there are
any problems with my proposed patch.

What do you think?

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#993161: pam: some remaining changes for DPKG_ROOT

[Sam Hartman]

> "Johannes" == Johannes Schauer Marin Rodrigues  writes:

Johannes> Hi Steve, Quoting Johannes Schauer Marin Rodrigues
Johannes> (2021-12-08 10:00:31)
Johannes> Since it has been more than a month without any reply I
Johannes> just uploaded a NMU of pam with the attached debdiff to
Johannes> DELAYED/10.  Those are the same changes as from
Johannes> https://salsa.debian.org/vorlon/pam/-/merge_requests/7 and
Johannes> our CI passes with those changes to pam
Johannes> https://salsa.debian.org/helmutg/dpkg-root-demo/-/jobs

I have attempted to cancel this NMU.
I've tried to explicitly nack this change without feedback from Steve,
and I stand behind this.
This change adds a maintenance burden that I'm not entirely comfortable
accepting either as an NMU or as a co-maintainer without full authority.

I'm guessing my previous statement on this was insufficiently clear.
Please wait for feedback from Steve before integrating this change.

Thanks,

--Sam


signature.asc
Description: PGP signature

Bug#993161: pam: some remaining changes for DPKG_ROOT

[Johannes Schauer Marin Rodrigues]

Hi Steve,

Quoting Johannes Schauer Marin Rodrigues (2021-12-08 10:00:31)
> support for DPKG_ROOT has been accepted by the maintainers of base-passwd,
> bash, coreutils, dash, dbus, debconf, debhelper, debianutils, dpkg, glibc, and
> shadow.
> 
> base-files and pam are the only two remaining source packages in the Essential
> set for which their maintainers did not yet agree to add support even though 
> we
> have tested patches for both source packages.
> 
> It has also (again) been more than a month without maintainer action for both
> bugs.
> 
> Please tell me what else needs to be done from our side before our patches can
> be accepted or explain why they cannot be accepted. We are still at the
> beginning of the release cycle, so right now is the best time to merge changes
> in order for them to get sufficient testing before the next stable release.
> Should bugs be found related to our patches in the future, I'm here to fix
> them.

Since it has been more than a month without any reply I just uploaded a NMU of
pam with the attached debdiff to DELAYED/10.  Those are the same changes as
from https://salsa.debian.org/vorlon/pam/-/merge_requests/7 and our CI passes
with those changes to pam
https://salsa.debian.org/helmutg/dpkg-root-demo/-/jobs

Should there be any problems related to these changes, please don't hesitate to
contact me so that I can fix them.

Thanks!

cheers, joschdiff -Nru pam-1.4.0/debian/changelog pam-1.4.0/debian/changelog
--- pam-1.4.0/debian/changelog	2021-12-06 20:11:31.0 +0100
+++ pam-1.4.0/debian/changelog	2022-01-17 11:10:48.0 +0100
@@ -1,3 +1,10 @@
+pam (1.4.0-11.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * support DPKG_ROOT in postinst (closes: #993161)
+
+ -- Johannes Schauer Marin Rodrigues   Mon, 17 Jan 2022 11:10:48 +0100
+
 pam (1.4.0-11) unstable; urgency=medium
 
   * Whitespace fixes in debconf templates.
diff -Nru pam-1.4.0/debian/libpam-modules.postinst pam-1.4.0/debian/libpam-modules.postinst
--- pam-1.4.0/debian/libpam-modules.postinst	2021-12-06 20:10:15.0 +0100
+++ pam-1.4.0/debian/libpam-modules.postinst	2022-01-17 11:10:24.0 +0100
@@ -5,16 +5,16 @@
 
 if [ -z "$2" ] || dpkg --compare-versions "$2" lt 0.99.7.1-3
 then
-	if ! [ -f /etc/security/opasswd ]; then
+	if ! [ -f "$DPKG_ROOT/etc/security/opasswd" ]; then
 		umask 066
-		touch /etc/security/opasswd
+		touch "$DPKG_ROOT/etc/security/opasswd"
 		umask 022
 	fi
 fi
 
-if dpkg --compare-versions "$2" lt 0.99.9.0-1 && ! [ -f /etc/environment ]
+if dpkg --compare-versions "$2" lt 0.99.9.0-1 && ! [ -f "$DPKG_ROOT/etc/environment" ]
 then
-	touch /etc/environment
+	touch "$DPKG_ROOT/etc/environment"
 fi
 
 if dpkg --compare-versions "$2" lt-nl 1.1.2-1 \
diff -Nru pam-1.4.0/debian/libpam-runtime.postinst pam-1.4.0/debian/libpam-runtime.postinst
--- pam-1.4.0/debian/libpam-runtime.postinst	2021-10-26 17:18:00.0 +0200
+++ pam-1.4.0/debian/libpam-runtime.postinst	2022-01-17 11:10:24.0 +0100
@@ -20,9 +20,9 @@
 	for configfile in common-auth common-account common-session  \
 	common-password
 	do
-		if [ -f /etc/pam.d/$configfile ] && \
+		if [ -f "$DPKG_ROOT/etc/pam.d/$configfile" ] && \
 		! fgrep -q $(calculate_md5sum $configfile) \
-		/usr/share/pam/$configfile.md5sums 2>/dev/null
+		"$DPKG_ROOT/usr/share/pam/$configfile.md5sums" 2>/dev/null
 		then
 			force=
 		fi


signature.asc
Description: signature

Bug#993161: pam: some remaining changes for DPKG_ROOT

[Sam Hartman]

> "Johannes" == Johannes Schauer Marin Rodrigues  writes:

Johannes> Control: user debian-d...@lists.debian.org Control:
Johannes> usertag -1 + dpkg-root-support

Johannes> Hi Sam,

Johannes> Quoting Helmut Grohne (2021-09-24 18:14:28)
>> So if you continue refusing our patches, can you propose any
>> other way to move forward?

Johannes> it has been a month since your last mail, so I wanted to
Johannes> send a friendly ping to ask, whether there is anything
Johannes> else we can do to help you with this bug.

No.
I'm waiting for Steve to chime in.
I do owe you and Helmut an explanation of why I'm uncomfortable, but I
think that belongs outside of this bug.
If this were my package entirely, I'd accept the patch, but my rationale
for doing so would be because I respect all the work Helmut has done and
I'm uncomfortable standing in the way of that.
In a case where I'm not really the maintainer, simply someone helping
out, that's not a good enough rationale.

Bug#993161: pam: some remaining changes for DPKG_ROOT

[Johannes Schauer Marin Rodrigues]

Control: user debian-d...@lists.debian.org
Control: usertag -1 + dpkg-root-support

Hi Sam,

Quoting Helmut Grohne (2021-09-24 18:14:28)
> So if you continue refusing our patches, can you propose any other way to
> move forward?

it has been a month since your last mail, so I wanted to send a friendly ping
to ask, whether there is anything else we can do to help you with this bug.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#993161: pam: some remaining changes for DPKG_ROOT

[Helmut Grohne]

Hi Sam,

On Fri, Sep 24, 2021 at 08:26:16AM -0600, Sam Hartman wrote:
> This seems... fragile.  In order for this patch to work, you're also
> asking the pam maintainers going forward to think differently about all
> file accesses in maintainer scripts.

While this may be true, I don't think it actually is that much we ask
here. So let's ask: What could possibly go wrong? Quite obviously, you
could add DPKG_ROOT where it doesn't belong or you could miss adding it.
Either failure doesn't affect native installation and only breaks our
use case. I don't see much potential for other kinds of breakage. That
seems relatively harmless to me. At worst, we'll be sending more
patches, right?

> I don't know that I'm going to be able to do that.

I'm not expecting that of you and I think you shouldn't either. The
belief that every package must have a single person or team responsible
for it seems to be rooted deeply in Debian and you appear to share it. I
don't believe in that. Consider what happens when you're not responsible
for keeping DPKG_ROOT working beyond reviewing and applying patches.

> Also, in my experience as a designer, that is a strong indication that
> things are happening at the wrong layer.
> This seems like an argument for a fakeroot-like thing,  or support from
> the kernel or filesystem or something, or from a library we're using for
> file access.

I fear you'll have to elaborate on this. If I had seen this other layer
that could solve it for us, believe me, I'd have used it right away
without bothering you with DPKG_ROOT. I fear that DPKG_ROOT is the only
technical solution for this problem I'm aware of.

> Having to pay attention to this detail at every layer seems fragile.

Really, you don't get around that. It is very similar to cross
compilation. In the "good old" native days, you could just call the
compiler. Now with cross building, every time you call a compiler, you
need to think and say whether you mean build or host. Admittedly, most
build systems pick host as a default. Still, it is the same thing here:
With DPKG_ROOT, you need to think which of those two systems you are
referring to. Is it the one we are installing or the one we are using to
install the former? There is little we can do to get around. All we can
do is paint the shed in a different color, but that doesn't remove the
detail we need to pay attention to.

> I appreciate that you value being able to do things purely in userspace
> without root.

root is not the issue. Both of us figured that we can solve the rootless
part in multiple other ways.

> I want to stress that I haven't really been sold on that at all.

That is quite evident from your mail. ;)

> The compelling argument for me was architectures where qemu was not
> available.

Yes, that.

> I also regret that I didn't see the implications of this from the
> beginning.
> The changes to pam-auth-update seemed less intrusive because of the
> structure of the code.

So maybe we need to take a step back again. I have an itch and look for
solutions. Johannes presented a solution and you don't like it for
reasons.  That sounds pretty normal to me. Now we're looking for
alternate methods to solve the problem. But none of the people I've
talked to were able to draft anything that would remotely solve the use
case. To me, it seems like we don't have any alternatives (besides not
solving the itch). This is where it becomes a little difficult. In the
absence of alternatives, maybe it is time to move forward? If we later
figure an alternative, discarding DPKG_ROOT support is relatively
simple.

We (proponents of DPKG_ROOT) see that it makes things more difficult for
maintainer scripts. For that reason our number one approach to
maintainer scripts is replacing them with declarative alternatives where
possible. A significant number of our patches only mentions DPKG_ROOT in
the description. When expressing maintainer scripts declaratively, the
DPKG_ROOT support goes into the tool (e.g. pam-auth-update) and the
burden shrinks. I think this is where we're heading, but in the mean
time, yes we will need DPKG_ROOT in maintainer scripts to make things
work at all.

So if you continue refusing our patches, can you propose any other way
to move forward?

Helmut

Bug#993161: pam: some remaining changes for DPKG_ROOT

[Sam Hartman]

[Steve, your thoughts welcome]

> "Johannes" == Johannes Schauer Marin Rodrigues  writes:

Johannes> Quoting Johannes Schauer Marin Rodrigues (2021-08-28
Johannes> 10:03:49)
>> Unfortunately, only the patch in the original message got applied
>> in 1.4.0-10 but I posted an updated patch in message #23 of that
>> bug.
>> 
>> I attached a patch containing the remaining required changes.

Johannes> For your convenience, I created a merge request on salsa
Johannes> (and closed the old one):

This seems... fragile.  In order for this patch to work, you're also
asking the pam maintainers going forward to think differently about all
file accesses in maintainer scripts.

I don't know that I'm going to be able to do that.
Also, in my experience as a designer, that is a strong indication that
things are happening at the wrong layer.
This seems like an argument for a fakeroot-like thing,  or support from
the kernel or filesystem or something, or from a library we're using for
file access.
Having to pay attention to this detail at every layer seems fragile.
\
I appreciate that you value being able to do things purely in userspace
without root.
I want to stress that I haven't really been sold on that at all.
The compelling argument for me was architectures where qemu was not
available.

I also regret that I didn't see the implications of this from the
beginning.
The changes to pam-auth-update seemed less intrusive because of the
structure of the code.

--Sam

Bug#993161: pam: some remaining changes for DPKG_ROOT

[Johannes Schauer Marin Rodrigues]

Quoting Johannes Schauer Marin Rodrigues (2021-08-28 10:03:49)
> Unfortunately, only the patch in the original message got applied in
> 1.4.0-10 but I posted an updated patch in message #23 of that bug.
> 
> I attached a patch containing the remaining required changes.

For your convenience, I created a merge request on salsa (and closed the old
one):

https://salsa.debian.org/vorlon/pam/-/merge_requests/7

Thanks!

signature.asc
Description: signature

Bug#993161: pam: some remaining changes for DPKG_ROOT

[Johannes Schauer Marin Rodrigues]

Source: pam
Version: 1.4.0-10
Severity: normal
Tags: patch

Hi Sam & Steve,

thanks a lot for fixing #983427!

Unfortunately, only the patch in the original message got applied in
1.4.0-10 but I posted an updated patch in message #23 of that bug.

I attached a patch containing the remaining required changes.

Thanks!

cheers, josch
diff -Nru pam-1.4.0/debian/libpam-modules.postinst 
pam-1.4.0/debian/libpam-modules.postinst
--- pam-1.4.0/debian/libpam-modules.postinst2021-01-30 23:09:52.0 
+0100
+++ pam-1.4.0/debian/libpam-modules.postinst2021-08-28 07:49:06.0 
+0200
@@ -5,16 +5,16 @@
 
 if [ -z "$2" ] || dpkg --compare-versions "$2" lt 0.99.7.1-3
 then
-   if ! [ -f /etc/security/opasswd ]; then
+   if ! [ -f "$DPKG_ROOT/etc/security/opasswd" ]; then
umask 066
-   touch /etc/security/opasswd
+   touch "$DPKG_ROOT/etc/security/opasswd"
umask 022
fi
 fi
 
-if dpkg --compare-versions "$2" lt 0.99.9.0-1 && ! [ -f /etc/environment ]
+if dpkg --compare-versions "$2" lt 0.99.9.0-1 && ! [ -f 
"$DPKG_ROOT/etc/environment" ]
 then
-   touch /etc/environment
+   touch "$DPKG_ROOT/etc/environment"
 fi
 
 if dpkg --compare-versions "$2" lt-nl 1.1.2-1 \
diff -Nru pam-1.4.0/debian/libpam-runtime.postinst 
pam-1.4.0/debian/libpam-runtime.postinst
--- pam-1.4.0/debian/libpam-runtime.postinst2021-08-26 21:43:23.0 
+0200
+++ pam-1.4.0/debian/libpam-runtime.postinst2021-08-28 07:49:06.0 
+0200
@@ -20,9 +20,9 @@
for configfile in common-auth common-account common-session  \
common-password
do
-   if [ -f /etc/pam.d/$configfile ] && \
+   if [ -f "$DPKG_ROOT/etc/pam.d/$configfile" ] && \
! fgrep -q $(calculate_md5sum $configfile) \
-   /usr/share/pam/$configfile.md5sums 2>/dev/null
+   "$DPKG_ROOT/usr/share/pam/$configfile.md5sums" 2>/dev/null
then
force=
fi