Bug#924401: #924401 base-files fails postinst when base-passwd is unpacked
On Mon, 22 Feb 2021, Colin Watson wrote:
On Mon, Feb 22, 2021 at 07:33:10AM +0000, Tim Woodall wrote:
As far as I can see, making base-passwd not essential, only required,
and then making passwd and base-files pre-depend on base-passwd the
system seems to bootstrap /etc/passed and /etc/group OK.
That also seems to conform to the debian policy. The oddity is that
base-files and passwd only actually need to depend on base-passwd, not
pre-depend on it as they only use /etc/passwd and /etc/group in the
postinst scripts but the debian policy doesn't seem to consider this
case.
base-passwd is independently essential to the functioning of the system
as it currently stands, not just because base-files and passwd need it.
As such I do not consider it correct to remove the Essential flag from
base-passwd and won't be doing so.
My view on this is that policy's definition of Essential should, for the
time being, be refined to indicate that it only applies after the
package has been configured at least once. Independently, I agree with
other comments on this bug to the effect that it would be useful to
extend dpkg such that initial copies of the essential files provided by
base-passwd could be written without having to run base-passwd's
maintainer scripts (something like the ability to provide an initial
version of a configuration file without making it a full conffile),
which would then allow simplifying the process, but I see no reason to
block policy refinements on that; the policy manual is a living document
and we can always update it again later once it's possible to simplify
the bootstrapping process further.
This can work. but I think there's a separate piece of metadata that is
missing. Essential: yes actually encodes two pieces of information:
1. That the package is available and usable even when it's not configured.
2. That you can rely on the existence of the package and so do not need
to include an explicit dependency to it.
Making base-passwd not essential would mean that every package that
depends on it should include at least a transitive dependency to it.
That seems ludicrous - so I agree with Colin that base-passwd should be
Essential.
But that then leaves the problem that essential also encodes 1.
I think there should be another piece of metadata
"ConfigureOptional: yes" (or something that encompasses packages
that do not need configuring to work)
That way, two, completely isolated packages A and B could be marked
"ConfigureOptional: yes" and use each other in their postinst scripts
(and declare themselves as dependent on each other)
Apt would then need to understand that circular dependencies can be
broken by unpacking, but not configuring ConfigureOptional packages.
There are a number of ways of solving the bootstrap tools problem of
automatically determining the correct order to configure the packages
without having to remove base-passwd from Essential.
1. make passwd and base-files depend on base-passwd without removing the
Essential: yes flag from base-passwd (Possibly by updating to policy
manual to state that Essential: yes packages CAN (Should?) state a
dependency on other Essential: yes packages. This would go in tandem
with Colin's suggestion to update the policy to state that Essential:
yes merely requires that the package guarantees to be available if it's
been configured at least once - and anybody outside of the essential set
itself can assume that)
2. update dpkg to explicitly create these files if they don't exist,
possibly by way of a type of "create only" conffile. This would have
general use as quite a lot of packages use a postinst script to install
configuration for the first time. The first example I found was for
python3:
[ -f /etc/python3/debian_config ] || new_config_file
base-passwd would then use this facility and would strictly conform to
the current Essential: yes policy.
FWIW, it is possible to bootstrap a "system" that only includes 14 of the
23 Essential: yes packages in Buster that has everything you need to
install the remaining 9 without having bootstrapped them from outside
the system. It is, I presume, missing something that would prevent
anything from booting and it's only usable via a chroot on an already
booted system.
And there's absolutely nothing with "Essential:" anything other than
yes, which suggests that another possibility would be to have Essential:
yes and Essential: needs_configure but option 2 above feels like the
correct solution.
I've never looked at dpkg source, but if it doesn't look too daunting I
might try to put together at least a proof of concept for the idea of
"only create, never modify" conffiles
Regards,
Tim.
Reply to: