On Thu, Oct 23, 2014 at 01:11:40PM -0400, Joey Hess wrote:
> Santiago Vila wrote:
> > Instead, the work of debootstrap is precisely to guess the right order
> > in which packages should be configured so that everything work.
> >
> > In other words, essential packages should not get in the business of
> > breaking dependency cycles, because that's debootstrap job.
> >
> > This way, maintainer scripts in essential packages are kept "clean"
> > and all the hacks required for bootstrap are "accumulated" (so to speak)
> > in debootstrap and similar tools.
>
> As a debootstrap maintainer, I can't say I agree with this.
Well, I was talking about hacks in the general sense (I didn't mean to
be pejorative here), i.e. the kind of trick that a tool like
debootstrap needs to use to achieve its goals. There are many kind of
hacks, and I'm quite confident that the current package will surely
have only the ones that are really required.
> There are very few hacks and special cases of ordering in debootstrap today,
> and for our sanity we'd like to keep it that way. I consider such
> complications to be warts that need to be gotten rid of eventually.
>
> Just compare /usr/share/debootstrap/scripts/{sid,sarge}. Which would
> you rather maintain?
I certainly see that the sid script is a little bit shorter than the
sarge script, but I don't see that any of them is really complex.
> And BTW that "sid" script works for 5 different
> releases of debian, largely because it's not full of special cases and
> hacks specific to particular releases.
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.
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.
> > 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.
>
> 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.
The Depends field is implicit among the set of essential packages.
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.
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.
Thanks.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
