On Fri, 20 Aug 2010 14:52:16 +0100
Wookey <wookey@wookware.org> wrote:
> +++ Neil Williams [2010-08-20 09:17 +0100]:
> > 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?
Absolutely. I do not want multistrap tied to Ubuntu release cycles. (I
don't want any Debian package I maintain to be tied to Ubuntu release
cycles.) It's a native Debian package and I don't have time to support
it in Ubuntu. The changes are too invasive.
> 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.
It's an unwanted burden from my perspective. A separate source package
means that I'm not the one to blame when the config files break.
> 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.
Ubuntu is a derivative, the Grip ones will move elsewhere after Squeeze
(they are not packaged currently, just sitting in SVN).
> Debian's Debootstrap has ubuntu configs in it. I think multistrap
> should too for the same reasons.
That is down to d-i, it wouldn't be my choice.
> > > 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.
Depends if apt itself supports that combination.
> 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.
... and Ubuntu specific. I don't have a problem with specifying that
repositories for multistrap need to be in a particular form, at least
until after Squeeze.
> 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?
I don't think this should be done in multistrap itself. I am also not
convinced that the rule is that black-and-white. Packages can look
after these things themselves, it doesn't have to be something done
from outside (which, IMHO, is usually the wrong way to do this).
> Exactly how we achieve that probably requires some more discussion.
> But if we can agree the objective, that would be a good start.
If this is upstart-specific, then I cannot allocate time to that until
after Squeeze is released.
> 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.
For Debian chroots, I haven't seen such problems.
> 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).
The crosschroot and chroot conf files for Debian/Emdebian are in the
Debian multistrap package currently. That won't change until after
Squeeze because there are issues around how a pdebuild-cross tarball is
adjusted to a different architecture which may or may not get more
hand-holding support.
> > > 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.
The patch itself still needs improvement for the wildcard issue and
there are other unresolved issues resulting from the loss of the
"suite" identifier in the rest of the code.
> 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).
I'm suggesting that, at the moment, flat URL's might just be
unsupported - mainly because I don't have time to implement, test and
support such a large change.
This is completely the wrong timing for me. Multistrap in Squeeze is
fine - one or two minor issues that I was considering supporting via
experimental - just like my other packages. That leaves me with the
time I need to sort out Emdebian Grip Lenny and Emdebian Grip Squeeze.
Ubuntu support is a significantly lower priority than simply getting
Grip updated and in a decent shape for the upcoming Debian release.
Release time was always going to be the worst possible time to consider
major structural changes to packages.
> > > + # 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.
I'm not sure why you have two wildcard matches in the first place. I'm
also not convinced that the reliance on a trailing slash is itself
definitive for this situation.
> 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.
More scripts like device-table.pl could be part of multistrap or part
of multistrap-helper packages from derivatives.
> > 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?
Can you put all your changes into a branch so that I can test it
properly? (Having said that, I won't have time to do that testing for
at least a couple of weeks.)
> > 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.
I am concerned about how the changes impact on existing support and
what happens internally when the suite is undefined. Also, I just have
to concentrate on other stuff during the release process - changes to
multistrap (or other packages) for support outside Debian/Emdebian just
won't get much of my time for a while.
--
Neil Williams
=============
http://www.data-freedom.org/
http://www.linux.codehelp.co.uk/
http://e-mail.is-not-s.ms/
Attachment:
pgpHRXBqFGL7x.pgp
Description: PGP signature