On Tue, Jun 30, 2009 at 03:29:08PM +0200, Simon Richter wrote: > a few days ago I asked on #debian-dpkg whether it was possible to get a > mechanism for adding new architectures to dpkg by dropping extra tables > into a specific directory.
I've cc'd #455501 on this, as that is still an open thread on what to do about the linux uclibc targets, and the last suggestion there was for: uclibceabi-linux linux-uclibceabi linux[^-]*-uclibceabi uclibc-linux linux-uclibc linux[^-]*-uclibc uclibceabi-linux-arm uclibc-linux-armel uclibc-linux-<cpu> uclibc-linux-<cpu> I'd like to suggest that the form in triplettable should instead be: uclibceabi-linux-arm uclibc-armel uclibc-linux-<cpu> uclibc-<cpu> As this is consistent with other arches there in that we assume 'linux' by default, and only add the extra qualification for non-linux kernels. I've been building uclibc toolchains and using them for active development for more than two years now, originally with the old ABI and most recently with gcc-4.4 and EABI, and this has been working well ... But that said, I now _don't_ think we should add these to dpkg by default, if anything we should _only_ more formally define the form that should be used. But more on that in a moment. > Given that these tables are ordered by regex specificity and that there > ought to be at least some arbitration in the architecture namespace, it > appeared to be the best solution to simply add new architectures in the > dpkg package, whether they are official Debian architectures or not. Hmm, ok, that is indeed something of a problem for just dropping extra definitions in a foo.d for dpkg to read (which I'd also lobbied for previously). But we _do_ already have DPKG_DATADIR now, and I have used that successfully with the most recent toolchain I built. There are a few issues with it, but none that seem insurmountable. What other problems are other people having with that which make it an unacceptable solution at present? The basic concept seems sound, the only troubles I've seen are the usual issues that environment vars all have. What if we allow just a single set of foo-table.local files on each machine? That if present will override the packaged tables from dpkg, but will not be overwritten each time dpkg is updated. If people want multiple additional arches it will be up to the local admin to merge them into the *.local files provided for that use (along with any from the official set they require) ... > So I'd like to collect a wishlist here and ask for comments: > > Debian GNU arch GNU regex > ----------------------------------------------------------------------- > armebuc armeb-uclinux-uclibceabi arm.*b-uclinux[^-]*-[^-]*eabi > armeluc arm-uclinux-uclibceabi arm-uclinux[^-]*-[^-]*eabi I'm against defining these two for the same reason I'm against defining the linux-uclibc ones above. The _only_ reason for using these builds is you are really tight on space, which pretty much guarantees that _every_ actually useful build will be incompatible with every other (as there are gazillions of configuration options to include or exclude various things). Making some 'official' definition of what these consist of just doesn't seem practical -- either they will include _everything_, which aside from being impossible for things like MMU support, will simply make them too bloated and so useless for _everyone_ -- or they will be defined to suit the first player and everyone else will be left out in the cold. Either we should leave these as 'user defined' arches, that people can define locally as they please -- or probably better, use these as a standard form, that people can then customise to make their own custom uclibc_foo-armel arch. That _should_ work, but I haven't actually made a toolchain like that to prove it. A few autoconf globs may need to be tweaked in some things, but by eye most seem to have wildcards in the right places for this to work. Mostly I'm just not certain they all agree on _where_ in the name we have freedom to add things like that, but that doesn't seem unfixable (or undesirable to fix) either. > win32 i586-mingw32msvc i(3,4,5,6)86-mingw32msvc > win64 (to be decided by mingw maintainers) > cygwin32 i686-cygwin i(3,4,5,6)86-cygwin I'm against adding these because after some 8+ years of maintaining the mingw toolchain (since gcc 2.95), they are still utter vapourware, don't really fit with being a distro arch in any sensible way (there is nowhere you can install the 'native' packages), and aren't required at all for creating a mingw-cross development environment hosted on Debian systems. People have been cross building for this target for many years now, and every effort that has started with defining what to call the arch has amounted to absolutely nothing at all. In the meantime, plenty of people and projects seem to be getting their work done with this toolchain just fine. We even dropped some of the above 'arches' from dpkg-cross a couple of years ago when that was merged with dpkg, and I have no link to offer re any real complaints about that which I'm aware of to date. I think the double handling of building 'native' packages that will never be used and then dpkg-cross'ing them is an 'obvious' reuse of existing cross build methods, but one that fits badly to an arch that doesn't follow the norms of a Debian system at all. If people really want to do this, then IMO they should prove this first with local use of DPKG_DATADIR for now. It would be a mistake to complicate the dpkg-cross mechanisms to cope with this, and vice-versa. And however seductive this may look as an 'easy' first step, you aren't going to have to go too much further than that to hit nasty trouble. If we're going somehow support 'debs' of non-debian arches, we really need to answer the "how are they different" and "where are we going to put them" questions much more thoroughly before we concrete parts of that into dpkg. Anyhow, I'd been meaning to follow up to #455501 for a while now with a report on how all that was all looking, so this was a pretty good cue to get a coredump from me on that. I think the next step I'd like to see here now is some broader discussion on the known failings of DPKG_DATADIR, and a few more people thinking about the best ways to address that. Being able to locally define an arch is _very_ useful for embedded developers -- but enumerating every arch they define before we even get a chance to see if they make it out of the R&D lab seems intractable and wasteful of a still rather limited namespace. dpkg should probably stick to just defining arches that debian distributes, but provide us enough knobs to tweak for new arches to be easily bootstrapped, some of which may later become part of the project archives too. There may be other arches that we do want to add to dpkg already, but my feeling on this particular lot is that pretty much all of them will come back to bite us later if we hardcode this in the distro dpkg now. Thanks for giving us some time to have another look at what to do about all this though ... It would be really nice to bed down a few more of the things that we are actually pretty sure about now ... Cheers, Ron -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
