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 ascertained. > 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 now. > 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 ============= http://www.linux.codehelp.co.uk/
Attachment:
pgpKa2rWivUzu.pgp
Description: PGP signature