[Piuparts-devel] Bug#1036705: override: adduser:admin/required

[Sebastian Ramacher]

Control: tags -1 trixie

On 2023-05-24 19:40:48 +0200, Helmut Grohne wrote:
> On Wed, May 24, 2023 at 06:54:01PM +0200, Cyril Brulebois wrote:
> > Watching from the sideline, this seems to come in horribly late.
> 
> How am I not to agree with this?
> 
> > > apt used to depend on adduser and apt is required, so adduser is
> > > transitively required in bullseye. Johannes and myself worked towards
> > > making apt not depend on adduser and that work succeeded.
> > 
> > FSVO “success” then, given the rest of the mail…
> 
> I'm really sorry about this. None of us saw the deluser breakage coming.
> After all, we were "just" killing a dependency. We should have noticed
> that it was the last and thus possibly having bad effects, yes. We did
> not. When I caught one of Andreas' bug reports about this, I immediately
> informed the release team to not loose any further time. It was already
> horribly late back then. :-(
> 
> > Via olasd/#debian-release: adduser got that field, not apt.
> 
> Thanks.
> 
> > Same question as before, why not just add the dependency back?
> 
> That dependency is conceptually wrong now. apt does not need adduser
> anymore. I think the initial idea was to add it back, but Julian rightly
> pushed back on this.
> 
> A major technical goal was to push adduser out of the essential+apt
> package set (which hints that we should have paid more attention,
> sorry). Adding this dependency breaks that goal while adding protected
> or required does not, so we'd actually get what we wanted.
> 
> > Aren't we risking a redux of “we turned another knob, and now we're
> > discovering yet another issue”?
> 
> It is very difficult to disagree with this one given that I thought
> "Protected: yes" to be harmless earlier.
> 
> > But I'm very much worried about possible side effects at this critical
> > stage of the freeze.
> 
> I will not stand in the way of turning this back and adding the
> dependency back to apt. It seemed to me though that this was not the
> preferred solution and that a (FSVO) better solution was available.
> 
> In theory, "Protected: yes" should solve the issue for purging. It just
> happens that piuparts does deal well with this, so the remaining issue
> is one of having broken a QA tool rather than having broken something
> for real. I can try talking to Nicolas about possibilites of adapting
> piuparts instead.

At this stage of freeze, it's too late to experiment with Protected: yes
in required that would work in theory, but where we know that one of
them fail in practice (by breaking at least piuparts) and for the other
we don't have any data.

So, as discussed in today's RT meeting, let's postpone this change to
trixie (or any other solution that isn't apt depending on adduser).

Cheers
-- 
Sebastian Ramacher