[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debian Social Contract

On Tue, 28 Jun 2011 01:03:22 +0200
Yann Dirson <dirson@debian.org> wrote:

> Jonas wrote:
> > Joke aside, I am aware that technical changes are big.  I just expected 
> > social challenges in finding consensus too, and am glad to learn if that 
> > is not the case.

This thread is getting ahead of things. I don't want to discuss details
of exactly how this will be done here because I've not had a chance to
discuss these ideas with ftp-master directly yet.

> Yes, there seem to be social challenges to deal with - or at least my
> short and recent experience with emdebian tools seems to show.
> Emdebian tools are part of Debian, which is a step in the right
> direction for integration of Emdebian into Debian proper. 

Let's expand that a bit. emdebian-tools as a package has gone away, as
has emdebian-rootfs, as has apt-cross. emdebian-grip is a package which
has been included in Debian since Lenny so that Debian machines can
process packages for Emdebian Grip. It is this processing which is being
considered for inclusion into mainstream Debian infrastructure, not
multistrap (which is already a Debian package, as we're all aware).

There is and always has been huge churn in the tools used by Emdebian.
Most of them have not been of particularly good quality (many
haven't deserved to be part of Debian and I'm working on removing
those, once alternatives become available). Most have relied on
hacks upon hacks upon hacks. dpkg-cross is a classic example
- it stinks and causes immense amounts of aggravation but it is what we
have and until MultiArch delivers results there will be nothing better.

This isn't about the tools, this is about the conversion of Debian
packages into Emdebian packages on a server.

Multistrap is just something which I hacked together because it was
useful and which is now suffering from the results of feature creep. It
is not a core tool for either Emdebian or Debian but it can be useful.
It can be a replacement for debootstrap where debootstrap fails to
handle situations which are common in embedded deployment but it will
not be the bootstrap tool for the main Debian processing because Debian
doesn't need to rely on apt to create a bootstrap.

What is core to Emdebian are three things:

0: Getting Multi-Arch to a point where Emdebian Crush can be restarted
as a cross-built binary-incompatible spin off Debian without coreutils
and without perl.

1: Getting Emdebian Grip processing (which converts natively built
Debian packages into smaller, binary compatible, Emdebian Grip packages
using an architecture-neutral method which itself is based on the
methods within dpkg-cross) included into the main Debian buildd
infrastructure in a way that is, as yet, completely unknown.

2: Getting cross-building toolchains built within the Debian buildd
infrastructure in a way that works with MultiArch.

Out of those things, various tools have been created, each of varying
levels of merit. dpkg-cross is one, multistrap is one, xapt is one.
Multistap doesn't care where the packages come from. What I'm trying to
sort out here is that we change where the packages are processed so
that Emdebian Grip benefits from the work of the release team with
regard to testing migrations and point release updates and even
security fixes. If we can get that done it will free up a lot more of
my time to smooth out the other rough edges but there are things called
priorities here.

Issues around trimming back multistrap to something which is actually
cohesive are completely unrelated to the processing of Grip on buildds.

Please separate the two issues and allow the people doing the work to
actually get the larger tasks done without nagging about trivialities.

This isn't about putting the entirety of "Emdebian" into Debian. It is
about putting the processing of one part of Emdebian, specifically
Emdebian Grip, into the Debian infrastructure using methods which are,
as yet, completely unknown.

There is a huge amount of work to do before any details can be

> However, my
> experience is that the documentation for this tools has lots of places
> for improvements, and that the tools themselves still have a lot of
> rough edges.

The tools have rough edges because the methods which we currently have
to suffer are rotten. Creating an -$arch-cross package is a stupid idea
(due to the required dependency mangling) but it is the only way to get
things done until MultiArch delivers. 

Perfection is the enemy of good. What we have is light years from
perfection but it can be useful, it can work and people do find it
useful. The cracks show up continually because the underlying methods
are all hacks. Papering over the cracks with docs is NOT the answer, we
have to fix the foundations and that means getting the hard work done
of changing the infrastructure. It means MultiArch, it means Grip
processing within Debian and it means throwing out our hacks. What we
have cannot be perfected because it is built on a house of cards. We
can only fix the foundations by having the time to work on the hard
technical challenges which gave rise to the original hacks. We have to
stop fixing the cop-outs and fix the real problems.

Multistrap is not part of this discussion - the inclusion of
Emdebian Grip into Debian has no bearing on the disagreements over
multistrap, it is about getting packages processed for Grip within the
Debian infrastructure. Multistrap is about using the results of
whatever processing we use, whether or not the processing gets
done within Debian. Please don't conflate the two issues.

The issue of including Emdebian Grip into Debian is a matter of the
emdebian-grip package and this package would become radically simpler if
packages could be selected for Grip as part of the buildd network.
However, I have no proposal for the technical details that would make
this happen. As Jonas states, these technical issues are big and need
discussion with ftp-master. I will not pre-empt those discussions here. 

The overall idea has received consensus that it is worth investigating
and that's as far as we can go. I'm planning on starting discussions
about the details at DebConf. There would have been no point if the
consensus had been to retain separate processing but considering the
amount of work which this involves, it is not surprising.

> However, many of the few bugreports I have attempted have been
> received as if those two aspects had no importance whatsoever - to the
> point of getting told that the manpage is already too large and cannot
> hold all information, and that the wiki is a better place for
> documentation. 

Nothing to do with the inclusion of Grip into ftp-master.

> That leaves me wondering what to do about the load of
> other reports I would have done - I am already quite discouraged to

(you and me both.)

> My guts feeling is that such a position gets in the way of usability,
> gets in the way of bringing more users to emdebian (if not worse), and
> does not match the quality standards of Debian (as a single example,
> no core Debian tool has its authoritative documentation in a wiki as
> prefered to inside the package).

Multistrap is not a core tool for Emdebian Grip. Different issue and a
trivial one compared to the challenges which dominate Emdebian right

> It would be just great if Emdebian could follow in Debian's step, and
> my opinion is that it is even necessary for integration in the Debian
> ecosystem.

OK, there we agree. Differences over how the docs are written has
nothing to do with whether the processing of packages for Emdebian Grip
can be handled by ftp-master.

> Some references:
> http://bugs.debian.org/630258
> http://bugs.debian.org/630406
> http://bugs.debian.org/631241
> http://bugs.debian.org/630314

None of which relate to Emdebian Grip, only to multistrap. Separate
issue. I am looking at exactly which bits of multistrap need to be
removed and how the docs will be reorganised but none of the bugs you
quote above did anything to help that process except delay it.

I do not want to be distracted into making large scale changes to
multistrap just when it would be most beneficial to Emdebian to be
working on the technical challenges of migrating the infrastructure of
the actual package processing.

Please, give it a rest and do something more productive. Let me get on
with the infrastructure stuff and get a point release of Emdebian Grip
Squeeze out of the door. That is the task which will bring the most
benefit to users of Emdebian right now.


Neil Williams

Attachment: pgp6jjGg74Nvu.pgp
Description: PGP signature

Reply to: