On Fri, 13 Mar 2009 13:54:38 +0100 Simon Richter <sjr@debian.org> wrote: *sigh* - time to call a halt and face the problems head on. So, let me spell things out, plain and simple. > > >, since > > > they have entirely different objectives > > > Not entirely different - the objective for the packaging tools is > > actually the same, to have packages install cleanly without changes on > > systems with a different architecture triplet. > > I'm not sure this can be achieved at all, as we still need a root > filesystem that isn't prefixed with the architecture triplet. That isn't acceptable - the current situation is untenable and a replacement must be found. The only current candidate is multiarch and what looks like an inevitable handler within dpkg to move certain paths around where necessary. This handler would later use DpkgClass support to intelligently handle files within packages that dpkg-cross currently considers "interesting" whilst dropping other files where there is no chance of executing them (typically, ordinary binaries). dpkg-cross has no future, neither does apt-cross. There is no possible mechanism for retaining the current methodology - it is fundamentally broken (because it tries to work around standard tools instead of moving with them) and it has shown that it cannot support the original aim, to allow sufficient portions of Debian to be cross-built sanely. I've worked with the code (almost exclusively) for two years now, I think it should be clear that I have no desire to do so for another two, let alone another ten. apt-cross, in particular, is already moribund. The only reason this is an issue at all is that it has taken 10 years to get to the point where we finally need to drop dpkg-cross and therefore we've got used to something that was never truly capable of being supported for the long term. That is not sufficient reason to retain it - it is a clear and adequate reason to remove it. I have no desire to release dpkg-cross or apt-cross with Squeeze. Their time has come and gone. I'm grateful for what the tools were able to support during the time that they were useful but *that time has passed* and both are now holding back development of stable, usable, friendly and reliable cross-building methods in Debian and Emdebian. Right now, there is no greater single barrier to Emdebian Crush than apt-cross and it's reliance on dpkg-cross instead of dpkg. If we want Emdebian Crush 2.0, we need to drop dpkg-cross. That is the reality - unless we drop dpkg-cross and apt-cross before the toolchain freeze for Squeeze, Emdebian Crush 2.0 might not release at all. We would face exactly the same issues in Squeeze+1 without the opportunity that currently exists to get our changes into dpkg, making it hard to see how Crush could recover. > The other issue is that generally, the 32/64 bit distinction does not > necessarily mean that we use a different triplet. i386/amd64 does, at least > in Debian, but that is optional as well and could be changed in the gcc > package, which would give us a situation where only clearly incompatible > arches need to be installed into a triplet directory. If things change, we continue to adapt. Never been a problem for us in the past. However, if we ignore the opportunity to get our needs addressed within the core Debian infrastructure, we only make things harder for the future. > > >, and there is generally no need to > > > install anything but libraries and headers into /usr/<triplet> -- so I > > > don't think there is a pressing need to replicate a filesystem hierarchy > > > standard below a triplet directory. > > > True, however, that is not a sufficient reason to not > > move /usr/<triplet> to /usr/lib/<triplet> and /usr/include/<triplet> > > if it means getting such support into the core Debian packaging tools. That is about the size of it, yes. > Indeed, however this makes building stuff without the packaging tools a lot > harder I disagree - it makes it about as hard as it is already. What's different is that the mulitarch method is untested and unfamiliar but that is hardly surprising. OK, so multiarch may need more changes in the future to make things easier but multiarch is the only viable option and we cannot afford to block ourselves into a corner by ignoring it or refusing to make it work for us. > -- for example I need to patch gcc to recognize these paths if I > build gcc by hand. Someone had to patch gcc originally to make that support available, the same needs to happen here. Debian makes lots of changes to gcc for Debian needs, I really don't see that this can be used as an excuse to block the original objective - getting cross-building support into the core Debian packaging tools. The price of that support is multiarch. > It might be a lot easier to have the packaging tools > handle the "current" layout than to patch all the software that assumes > that software is generally installed into "include" and "lib" dirs under a > common prefix (such as most GNU software that uses the autoconf macros to > find installed software). > > Simon That can't work either. If the core Debian packaging tools are going to change in our favour at all, they are going to change to support multiarch - that much has been made clear repeatedly. If cross-building doesn't get up to speed then the packaging tools could change in a way that breaks all cross-builds, not just the harder corner cases. Multiarch isn't perfect for Emdebian but it is the best we are going to get, it is immeasurably better than what we have (principally because it can support future development needs) and we need to work with it and modify it to our needs. The current layout is simply not an option. It has gone as far as it can go, it simply cannot cope with forthcoming changes within dpkg or likely future changes. There is no way to make any progress with cross-building larger parts of Debian without an unsustainable mess of multiple layers of package patches, specialised tools and horrible hacks to what should be standard tools. Perpetuating the current system will only add back layer upon layer of new hacks, to replace the ones I've been working to remove, as our methods once again fall behind core Debian methods and get left to bitrot. If that happens, there will be no way to expand Emdebian Crush. A lot of progress has been made in removing old hacks from the current tools but there is nowhere left to go. The next step is to get support into dpkg - only then can any of the bugs in apt-cross and the more complex bugs in Emdebian Crush actually get fixed. That much has been inevitable from the start. I think that it is highly unlikely that Emdebian Crush will ever be able to support more than ARM or armel (i.e. one architecture at a time) *unless* the current cross-building methods are dropped - the workload is simply too high. I do not think that is acceptable. There are problems with using multiarch, yes, but the prize is infinitely more important than the difficulties. If some things need to be adapted to work with unchanged core tools then so be it - if some things still need specialised wrappers, so be it. The aim is and has always been to get the core cross-building support into the core Debian packaging tools and that means dpkg and no dpkg-cross, it means apt and no apt-cross and it means that cross-building needs to adopt and modify multiarch to the point where we can all use it, albeit with wrappers and support tools where necessary. Then, we can work on absorbing those wrappers into the new dpkg when the time comes. Multiarch is the only deal on the table and we need to make it work, even if certain features/artefacts of the current system are lost. Please don't argue the points any further, we may lose all that we have gained so far. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
pgpYBUDgSymvf.pgp
Description: PGP signature