Re: multistrap on ubuntu
+++ Neil Williams [2010-08-20 09:17 +0100]:
> On Fri, 20 Aug 2010 02:30:45 +0100
> Wookey <wookey@wookware.org> wrote:
>
> > 1) There were no configs for maverick or ubuntu cross-building-chroots
>
> Please put these into a new package - this is how the other
> configuration file groups are expected to be handled, e.g. debian-live
> or custom hardware / derivative distribution groups.
Are you sure it's worth it for a few hundred bytes of configs? It's
useful for the Debian version to be able to create ubuntu
chroots/images and vice versa and it's sufficiently common that putting
the configs in the normal package makes sense to me.
Clearly there are limits to multistrap collecting the configs for
everything in the world, including all possible users and deriviatives,
but in this case I don't think a separate package is warranted.
Debian's Debootstrap has ubuntu configs in it. I think multistrap
should too for the same reasons.
> > 2) Multistrap does not deal correctly with 'flat' source URLs, as
> > produced by apt-ftparchive.
>
> Has this been tested with the current version in SVN and with
> explicitsuite=false ?
No, but the point is that it should still be possible to use flat URLs
with explicitsuite=true because you may have other stanzas where you
need to be explicit about the suite.
explicitsuite=false applies to _all_ the stanzas and you might not
want that. The flat URLs are 'special' with regard to suite/component
and should be dealt with acordingly.
> The existing suite support needs to be retained - including
> $package/$suite without recourse to pinning, yet allowing pinning to
> work where necessary too.
Of course. I haven't taken any of that away. It's just that for flat
URLs the suite is null by definition so the existing mechanism of using
"$package/$suite" results in an error but we don't want to turn off
explicitsuite for _everything_.
> > 3) Multistrap does not try to stop packages running services in
> > postinsts.
>
> This needs to be configurable so that `dpkg --configure -a` can be done
> as part of the first boot process.
Yes - clearly you want real packages in that case.
Exactly how we decide whether we are doing a chroot or an image is a
good question. (yet another) explicit config option is probably the
right answer. However the (temporary) nobbling part should probably be
automatic according to this rule: "if doing the configuring in a
chroot, either natively or via qemu, then things must be temporarily
nobbled. If the image is intended to be a real image then this
nobbling must be reverted before running live.". Anyone disagree?
Exactly how we achieve that probably requires some more discussion.
But if we can agree the objective, that would be a good start.
Underlying this is the idea that multistrap can be used to make
chroots as well as real syustem images. The inital focus was real
system images, but I see no reason not to support making chroots too
unless it causes fundamental breakage. The alternative is to teach
debootstrap about multiple repositories but I think the idea of using
apt to do all the hard work makes a lot of sense so it's worth making
multistrap more capable in the 'making chroots' dept. It already works
suprisingly well considering all the things it isn't doing.
> > Discussion and details:
> >
> > 1) Configs
> >
> > I've created configs for maverick and lucid.
>
> I see those in current multistrap SVN but I'm not that happy with
> leaving them there, principally because I don't want all multistrap
> config files to expect to live in the multistrap package and I don't
> want multistrap bound to having to be released every time there is an
> Ubuntu release. Is there another source package which could be used?
> I'm thinking of moving the grip-* configuration files into one of the
> other source packages too. Configuration files for multistrap don't
> need to be in any particular directory, or managed by ucf or put
> into /etc/ - any directory is as good as any other.
Discussion above. We need to consider what is the base set of configs
multistrap supports out of the box and what is extra for other
packages to provide. The cross-configs should probably come from
pdebuild-cross for example. (maybe they already do - I am a bit
confused about that).
Having a release every 6 months is hardly a big imposition at the
moment, and there is no requirement to do that anyway - having configs
in the packages, as debootstrap does, is just a convenience. configs
for new releases can get added in the ubuntu version first and work
there way into the debian version over time in the normal way. I don't
see a problem there.
I'll see if there is some other sensible place for them to live, but
I'm not aware of one right now.
> > 2) Flat URLs
> >
> > My test case is:
> > deb http://people.canonical.com/~hrw/ubuntu-maverick-armel-cross-compilers ./
> >
> > Setting
> > source=http://people.canonical.com/~hrw/ubuntu-maverick-armel-cross-compilers
> > suite=./
> > components=
> > does not work, because then multistrap tries to qualify the specified
> > packages using the suite "./" and then fails to find e.g.
> > g++-4.4-arm-linux-gnueabi/ with a "Release '' not found" whinge.
>
> Only if explicitsuite=true?
yes
> > So I fixed up the code such that you can specify
> > source=http://people.canonical.com/~hrw/ubuntu-maverick-armel-cross-compilers ./
> > and multstrap ensures that suite and component are not set (for any source
> > ending in a path with a trailing slash).
>
> > The problem with this is that nothing now ensures that the specified packages
> > actually come from the specified repository, even if explicitsuites is set.
>
> I cannot accept such a patch.
Why not? I think you misunderstand. I don't mean that explicitsuite
stops working because this functionality exists. I mean that _for this
deb source_ you can't use the $package/$suite syntax because it is
meaninglyess and apt will fail to find the packages. My patch allows
explicitsuite to still work for all stanzas with 'normal' deb-source
lines - indeed that's the point: if you just turn explicitsuite off
then you don't need the patch.
Are you suggesting that one can only have a stanza with a
flat URL in it if one doesn't want do use explict suites in any other
stanzas? That makes no sense. We can't turn off explicitsuite on a
per-stanza basis can we? That could work, rather than the approach I
took, but that leaves it up to the user to get the config right, when
it's perfectly possible for the tool to just DTRT (ensure
suite/component are null for lat URLs).
> > The package/suite syntax cannot be used so I think that specifying package
> > pinning would be the only way to do it. Something to investigate one day, but
> > it's not a problem currently.
>
> It is a problem, I need to retain explicitsuite *and/or* pinning.
Nothing about this patch takes away that functionality - in fact it is
carefully preserving it.
> > + # don't set suite or component if URL is of apt-ftparchive trailing-slash form
> > + if (($mirror =~ /.* .*\/$/)) {
>
> That '.' must be escaped otherwise it is a wildcard.
both dots I presume. Will do.
> > 3) Nobbling services
> >
>
> > I fixed this the same way that debootstrap deals with it - by
> > replacing initctl and start-stop-daemon with little shell script that
> > say 'in chroot, doing nothing'. This is implmented in a script
> > chroot.sh which is called using the setupscript mechanism.
>
> If you want one setupscript to call another one, you can call the other
> setupscript from inside the first one. There is only one call from
> multistrap to a script which is expected to do everything necessary.
OK. So what I've done is right then. (so long as no-one wants to make
a real-system cross-build image - fortunately that makes little sense
right now - they are only for pbuilder/pdebuild-cross). But I can see
the 'run one setup script only' thing may cause issues for scenarios
we haven't envisaged yet. I guess if we provide standard 'subscripts'
for things like 'divert initctl for chroot use' then configs can use
them in their top-level scripts, and that should work fine. It's just
a matter of keeping things modular.
> > For real filesystems we need to do something a bit more sophisticated
> > - temporaily divert the files during the dpkg configure stage, but
> > then put them back again for when the system is booted on real
> > hardware. Aparently debootstrap has a little package that it installs
> > and then removes to accomplish this. Shall I file a bug about this to
> > keep it in mind?
>
> Are you thinking of pbuilder? or d-i?
perhaps I am - I only learnt that all this sort of thing went on yesterday.
> > And in fact I wonder if these scripts should go in a scripts dir under
> > /usr/share/multistrap/ just to stop mixing the scripts and the
> > configs? maybe it doesn't matter and shorter paths is good?
>
> In the same source package as the config file, not the multistrap one.
agreed. (that script should be in the same package as the config files
that use them, except that some things like 'standard chroot actions'
should probably be in the main multistrap package).
> > 5) Installing packages in un-specified stanzas
confirmed fixed in SVN
> > If there are no violent objections I'll check this lot in.
>
> Not just yet, please. Breaking explicitsuite is unacceptable.
Agreed. I have carefuly preserved its functionlaity, rather than
simply required that it was turned off for flat URLs to work. See
above for clarification.
Is that OK now?
> I won't have time to look at this today and I won't have a lot of time
> this weekend either (working on the Lenny update of Grip). However,
> please do not commit this patch. It breaks far more than it fixes.
I think we disagree there. I hope I've explained sufficiently above
that nothing broke, in fact.
Wookey
--
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/
Reply to: