On Thu, Nov 06, 2014 at 02:06:07PM +0000, Michael Tautschnig wrote:
> [ BCC'ing Santiago, Holger, Adam, Cyril ]
>
> Hi all,
>
> I'm refraining from quoting the preceding mails as most of you will have those
> in their inbox, and I'd rather summarise the situation right here:
>
> At least Santiago's and my opinion diverge on whether base-passwd is presently
> in line with policy on 3.8 Essential packages. Therefore the route from here
> appears to hinge on interpreting policy in one of two ways: my point is that
> base-passwd, at present, is not providing its functionality after just being
> unpacked - it does require postinst having been run. Santiago claims, if I
> interpret this correctly, that every package has to be configured at least
> once
> before being useful at all (irrespective of whether it is essential or not).
Yes, and I should add that my interpretation of policy is based on the
wording being used:
Since dpkg will not prevent upgrading of other packages while an
`essential' package is in an unconfigured state, all `essential'
packages must supply all of their core functionality even when
unconfigured.
The use of "upgrading" here suggests to me that the rule saying
"packages must work even when in unconfigured state" does not refer to
the temporary unconfigured state of essential packages while they are
being installed by debootstrap but instead the unconfigured state set
by dpkg when they are being *upgraded*.
I think that this interpretation is the best one to follow because
it simplifies greatly the job of package maintainers in general,
and essential package maintainers in particular.
The job of debootstrap is to put everything together so that we can
actually rely on the functionality provided by essential packages
after debootstrap has done its job.
By doing this, we transfer part of the complexity of the problem of
putting a complete system together from the individual packages to the
debootstrap tool.
In a previous email I said something like "we put the hacks in
debootstrap so that we don't have to put hacks in the individual
packages" (Joey didn't like the wording I used).
Well, debootstrap is not a hacky program really, it just unpacks and
configures the packages following an order which is known to be
good. But thanks to the fact that we made a certain set of packages
essential and thanks to debootstrap, we don't have to use, for
example, numeric UIDs in postinst, we can use "root" and "mail".
I think this is good and it's how we should do things.
In particular, I think it would be good that we consider configuring
every package at least once one of debootstrap's jobs, so that what
base-passwd currently does is allowed.
Now, a long patch is proposed for base-passwd. A patch which is quite
a lot longer than the required patch that would fix this in
debootstrap.
I can't honestly tell Colin that he "should not" apply the patch, it's
his package after all, but I should say that the patch seems ugly and
hacky to me, and it introduces an additional complexily which IMHO is
against the idea of having a tool like debootstrap to break the cycles
and avoid complexity in the packages themselves.
So, my opinion about the patch is that we should ideally not need so
much code in base-passwd if we can fix the same problem by applying a
one line patch in debootstrap.
In either case, this is an issue to be solved between debootstrap and
base-passwd maintainers, so I might better disappear and take a step back,
like KiBi recommendsd.
Thanks.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
