Re: Debian Social Contract
On Wed, Jun 29, 2011 at 07:12:09PM +0100, Neil Williams wrote:
> > > Multistrap is just something which I hacked together because it was
> > > useful and which is now suffering from the results of feature creep.
> >
> > In what way? It's a very useful tool, and in some ways has a better
> > design than debootstrap. It is becoming quite popular as a result.
>
> I agree that working from the original goals, multistrap is better than
> debootstrap. It copes with multiple repositories, it handles --foreign
> without bloat and is architecture-agnostic as a result. In those
> important aspects, multistrap has fulfilled the original objectives
> very well.
>
> The problems are:
>
> 0: The hooks and the inherited machine:variant support - the two
> mechanisms don't sit well together. One needs to replace the other. I'm
> unconvinced that hooks are actually a good idea, or even particularly
> useful compared to the setupscript and configscript and the hooks
> themselves seem particularly unfriendly.
>
> 1: The duality (common to all bootstrap tools) of one tool which both
> creates both root filesystems to boot and chroots for building other
> packages is confusing and causes documentation duplication.
>
> 2: The manpage is too long, it does need to be split and I'm thinking
> that multistrap needs a man.5 and possibly a man.8 but the wiki and the
> website will remain important resources for levels of detail and
> examples which simply won't work in a manpage.
I was thinking the current manpage could be replaced by a full doc
derived from it, and a new, shorter manpage could be put in place,
focusing on the essentials of using the tool on an existing config
(and that manpage could be part of the full doc as well, whether we
use docbook or asciidoc as a format).
> 4: apt and dpkg are fast moving and multistrap needs to adapt
> frequently and quickly. Too much complexity in the script hinders the
> maintenance of the core functionality.
>
> Multistrap needs to return to KISS and go back to being a small tool
> which does a known set of tasks very well and leaves the rest to
> everything else.
>
> It stemmed from the idea of trying to let multistrap create the entire
> rootfs in a single call. For simple systems that can still work. The
> goal of doing that for every possible system is not achievable and
> multistrap needs to step back and be confined to what it does best.
>
> Again, MultiArch will come to a partial rescue here because it will
> make it easier to setup cross-building pbuilder chroots and that entire
> side of multistrap may actually disappear. Equally, getting
> cross-building toolchains into Debian will ease the problem as well.
[...]
> > Neil - you worry about the emdebian grip integration stuff, and I'll
> > worry about these minor doc and config fixes in multistrap. How about
> > that?
>
> Multistrap may well need work to handle MultiArch (particularly in the
> complex unpacking routines which populate /var/lib/dpkg/info) and that
> will complicate things.
While multistrap gets adapted for MultiArch, and potentially looses
the ability to deal with squeeze, it may be worthy to fork it in some
way (looks like a better idea than trying to support both worlds), and
allow simultaneous installation of both flavours.
OTOH, going the way of smaller tools could prove to provide a way to
still share a lot of the code between the two flavours.
I suggest we more further discussion on this topic to a new thread.
> I need to keep one eye on multistrap but at a deeper level. It does (or
> soon will) require potentially disruptive changes and a lot of testing.
> This isn't a time to go tweaking minor doc details because the whole
> documentation will need a rewrite (and then a full re-translation).
I understand your point, which makes perfect sense for the flavour of
multistrap that's going to support MultiArch. OTOH, for those people
coming to it with squeeze as target, it would help much to understand
things, without having to stop on strange points in the doc. This
also seems to push for a fork.
Best regards,
--
Yann
Reply to: