[Pkg-shadow-devel] Transition plans for passwd.config to user-setup-udeb

[Christian Perrier]

(shadow package devel list added)

Quoting Joey Hess (joeyh at debian.org):
> Christian Perrier wrote:
> > Log:
> > perl is only available on the target system
> 
> > -        perl -e '
> > +        $chroot $ROOT perl -e '
> 
> It seems to me that one of the possible benefits of a user-setup
> udeb is being able to run before the target system is installed, so that
> as many questions as possible are asked at the beginning of the install.
> 
> Maybe it would be good to split off a prebaseconfig hook script in your
> user-setup udeb that takes care of actually setting the passwords, and
> leave the postinst script to just prompt for them, in a way that
> wouldn't need /target?


Well, certainly.

My current intent is having something ready to be used as is and not
too much different from current passwd.config which is known to work
(with a few quirks and hacks)).

So, this initial development is mostly aimed at having a base to
discuss whether a user-setup-udeb is the best thing to do or not.

The initial-passwd-udeb we currently build in shadow was the first
step and it has now been proven working. We still have a RC bug raised
for it but this is more a fake bug to just be sure we don't request
shadow to enter testing now.

I more or less had the following plan:

-have initial-passwd-udeb work as a test case: done

-move the code to user-setup-udeb in the D-I trunk: under way

-upload user-setup-udeb: to be done after the meeting if ACK'd by the
                         D-I release manager

-upload a new shadow *without* initial-passwd-udeb but still with 
 passwd.config so that testing installs with D-I beta1 are not broken
 to be done as soon as user-setup-udeb is uploaded

-request ftpmasters to remove the current inital-passwd-udeb

-after D-I beta2 release, upload shadow without passwd.config

The point is also getting rid of code specifically aimed at D-I in
shadow. Uncontrolled changes there are likely to break D-I in the
future if we keep such code there. For the moment, this is not a big
issue as I work on both teams and can sync things but who knows for
the future?


Frans mentioned possible concerns about the passwd.config code being
potentially useful for other needs than D-I. For the moment, I'm not
aware of any. For instance debootstrap does not use this code which is
only called when reconfiguring passwd.

Of course, when planning the removal of this reconfigure code, I'll
send a note to -devel just in case there are some needs I'm not aware
of.

I'd also like to get Ubuntu's input about this issue. Ubuntu currently
uses initial-passwd-udeb.