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.
> 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 ?
The existing suite support needs to be retained - including
$package/$suite without recourse to pinning, yet allowing pinning to
work where necessary too.
> 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.
> 4) Multistrap specifies the wrong path for the sources list when doing
> the initial package install if aptsources is specified. This doesn't
> actually seem to matter, but is confusing.
#593561 - fixed in SVN, pending.
> 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.
> I'm not sure quite how many configs we should carry and how they
> should be cascaded and named. e.g. we could have 'armel.conf' which
> changes between debian and ubuntu versions to point to relevant distro
> stuff. That would be easiest from the users POV, but it's dull having
> an Ubuntu patch for them to carry. We could keep armel.conf for Debian
> and have armel-maverick.conf for maverick etc. Similarly for
> crosschroot.conf and so on.
Hence another source package, please.
> 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?
> 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 regexp could be made more
> paranoid or possibly there is already some perl code for parsing such deb lines?
> 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.
> 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.
> + # 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.
> 3) Nobbling services
>
> This prevents a basic maverick chroot being multstrapped, as procps
> fails when it can't find upstart. In fact it's important to stop apps
> starting services, as higher-level services will result in things like
> apps in the chroot being bound to socket on the base system.
>
> 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 hte setupscript mechanism.
>
> however for cross-chroots we already call setcrossarch.sh.
>
> I'm not sure how the config cascading stuff works with multiple
> setupscripts options - do you get the first one, the last one, all of
> them? (in what order?). So I decided that it was alwyas correct for
> setcrossarch.sh to call chroot.sh which does the initctl nobbling.
> (because cross-build chroots are always hosted chroots not real
> filesystems.
Run with the --simulate option to see the one being used - naturally,
that is easier if each one has a different name.
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.
> 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?
> 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.
> 5) Installing packages in un-specified stanzas
>
> With this config file:
> General]
> include=/usr/share/multistrap/crosschroot-maverick.conf
> omitrequired=false
> configscript=
> setupscript=/usr/share/multistrap/setcrossarch.sh
> debootstrap=Ubuntu MarcinToolchains
> aptsources=Ubuntu Ubuntuports MarcinToolchains
> tarballname=pdebuild-cross.tgz
> noauth=true
>
> [Toolchains]
> packages=g++-4.2-arm-linux-gnueabi linux-libc-dev-armel-cross
> reinstall=binutils-multiarch
> source=http://www.emdebian.org/debian
> keyring=emdebian-archive-keyring
> suite=stable
>
> [MarcinToolchains]
> packages=g++-4.4-arm-linux-gnueabi linux-libc-dev-armel-cross
> reinstall=binutils-multiarch
> source=http://people.canonical.com/~hrw/ubuntu-maverick-armel-cross-compilers ./
>
> the initial apt install will try to install both the g++-4.4-arm-linux-gnueabi
> we asked for and also the g++-4.2-arm-linux-gnueabi we didn't. Exactly why is
> beyond my perl-fu to work out. Something to do with the cascading?
As with all issues about cascading, check with the --simulate option.
> I'm hoping Codehelp can sort that one out.
Not without access to usr/share/multistrap/crosschroot-maverick.conf -
where does it live?
> If there are no violent objections I'll check this lot in.
Not just yet, please. Breaking explicitsuite is unacceptable.
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.
--
Neil Williams
=============
http://www.data-freedom.org/
http://www.linux.codehelp.co.uk/
http://e-mail.is-not-s.ms/
Attachment:
pgpgUVX3xZzdp.pgp
Description: PGP signature