[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#766459: debootstrap: should not try to configure

Hi all,

I'm being heavily bitten by this one as well and I'm mildly shocked to see it
crop up this late in the release cycle. I'm not going to hide that I believe
this ought to be reassigned to base-files. I'll try to elaborate below.

Santiago Vila wrote:
> In this particular case, I believe the reason for the failure (that
> didn't happen before) is some change in base-passwd, not something
> that base-files does differently now.

I tend to disagree: base-passwd hasn't been touched since 2014-09-04, whereas
debootstrap only started to fail last week, when base-files 7.7 was uploaded.
It's this change I believe:



chown: invalid user: 'root:root'

Admittedly, though, this just exposes a problem that had been lingering for a
while as the calls to chown using root:root could have been invoked from several
bits of the postinst script.

> In principle, every essential package may depend on any other, and the
> set of real dependencies may change over time, so it's natural that
> debootstrap needs minor adjustments from time to time.

So would you expect some sort of versioned dependencies in debootstrap? As the
upload of base-files 7.7 showed, it is changes in packages that suddenly require
new hacks. And a key problem is that tools like debootstrap ought to work from
within, e.g., stable release to bootstrap future releases like testing or
unstable. Suggesting that a bootstrapping tool is changed due to updates in
another package is going to cause a major dependency loop as at least testing
efforts such as those of jenkins.d.n will be broken.

In fact it would be easier to codify this in dpkg than in debootstrap, I
believe, as dpkg would live in the same suite as the package to be installed.
But this sounds like very bad design indeed.

> > > You will find a more complete explanation of this in the logs for
> > > Bug#760568 where I'm asked no less than to depend on base-passwd,
> > > which is essential! IMHO, this is definitely not the way to go.
> >

Using the "essential!" hammer doesn't sound like a great argument when your
package is essential.

> > It's past time to be untangling the Essential hairball. Correct dependency
> > metadata is much more scalable than hacks in debootstrap.
> I agree that you may have a point here. In fact, in the aforementioned
> bug #760568 against cdebootstrap, which is very similar to this one,
> I suggested the idea that if the knowledge about right package ordering
> among essential packages were codified and written somewhere, other
> similar tools could use the same information without having to
> reinvent the wheel.
> I see now that the control file could be such common place to have
> that information, but I would like to see a little bit of *design*
> before doing anything which is not in policy yet.
> For example, we could use:
> * The same Depends field we are using for normal dependencies.
> * A new field for this particular purpose which dpkg and friends
> ignore under normal circumstances, and an environment variable which
> debootstrap may set to tell dpkg and friends that they should actually
> honor them instead of ignoring them.
> * An extension of the Depends field, much like <!stage1> is used in
> Build-Depends for build profiles.
> So yes, we could consider to codify this metadata (the fact that
> base-files postinst uses "chown" and expect the root user to exist,
> for example) in *some* way...
> > Stop being part of the problem, and add the dependency already..
> ... but please let us think about it first. Starting to add "Depends"
> field here and there in a random fashion "just because it makes
> debootstrap not to fail anymore" is not something I will be happy
> with.

I do fully agree that care must be taken, as dependency loops would obviously be
a major problem.

> The Depends field is implicit among the set of essential packages.

I'm not too sure about the "among" bit here? No doubt that this is implicit for
any non-essential package, but "among" them I'm not sure whether any rules apply
right now?

> If a tool like apt-get or dpkg really behaves in a different way when
> I add a Depends field which was already implicit, I think that there
> is something fundamentally wrong here.

Does dpkg really add the "essential" information into its dependency
information? Wouldn't this rather be seen as "ah, essential, so it must be
there?" At least briefly looking at dpkg's source code I cannot seem to see dpkg
considering this implicit dependency at all (unless attempting to remove an
essential package).

> So, to summarize: I'm not opposed to modify policy when it says that
> we don't need to include dependencies on essential packages, but if we
> decide to go that route, please let us do it according to some *plan*,
> not in a random fashion, because otherwise, IMHO, *that* would be the
> real hack.

I do appreciate being careful, but then bug fixes for a bug of normal severity
(#763405) shouldn't be causing RC bugs either.


Attachment: pgpgTH22h3Myq.pgp
Description: PGP signature

Reply to: