Re: Debian Social Contract
+++ Neil Williams [2011-06-28 08:17 +0100]:
> On Tue, 28 Jun 2011 01:03:22 +0200
> 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.
dpkg-cross is a perfectly sensible idea, which now has a 10-yr
pedigree. SOme of it's better bits have been absorded into dpkg some
time ago. It has limitations, and thus so does the cross-compilation
system it implements, but it's silly to say 'it stinks'. I plan to
improve it to allow packages to supply autoconf cache data, rather
than have it all contained in dpkg-cross (which makes no sense), for
example.
> 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.
> 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.
Actually IMHO 0 is getting Multiarch apt and dpkg to a point where they
correctly solve the 'determining and installing cross-dependencies'
problem, which is by far the biggest thing making cross-building
on Debian difficult and unreliable.
That might be the same thing you said in different terms. I hope to
make some progress on that with Michael Vogt this week.
> 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.
This is indeed a worthy goal.
> 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.
I didn't see Yann say anything about this. Perhaps you are refering to
a bugrep I haven't seen? (aha I see, refs below)
> > 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.
Partly. They also suffer from a limited number of developers and being
rude to people offering to help is not the best way to grow those
numbers.
> 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.
As stated above this is hyperbole at best.
> 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.
Most of this I do agree with. Implementing cross-dependecy resolution
using multiarch status and build-depency qualifiers, rather than
fiddling with xdeb forever is currently the best use of my time, I
believe. Then working with package maintainers and upstreams to fix
cross-building problems (some of which are throny), and implemnting a
distributed cached-value provision mechansim should make a good
proportion of Debian cross-buildable in a reasonably rigorous fashion.
I think continuous integration testing of that is also very important,
and I'm hoping to get that done in the next couple of months too.
> > 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.
Neil, Yann provided some useful fixes in suggestions in all those
bugs, and you were generally dismissive. I'm not surprised he's
discouraged.
Yann. I help maintain multistrap too, and I appreciate the above
bugreps, even if Neil doesn't. Your attention to detail is
commendable. I quite agree that saying 'no I won't documen't this
feature in the manpage - it's already too long - put it in the wiki
instead' is a ridiculous response. (630258 above)
Please don't feel dicsouraged.
> 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.
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?
Wookey
--
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/
Reply to: