On Mon, 23 Feb 2009 22:46:24 +1030 Ron <ron@debian.org> wrote: > On Sun, Feb 22, 2009 at 12:23:22PM +0000, Neil Williams wrote: > > > The rationale is, things like arm and uclibc have many possible variants, > > > and we cannot possibly provide them all by default. > > > > archtable.d/ was meant for this support - although the name does tend > > to indicate only one side of the table but that can be changed. > > Ok, I'm probably a bit confused still about where everything is planning > to move to, I had thought dpkg-cross was going to mostly disappear, but > if it fits better there, I'm not really fussy about what it's called. The dpkg-cross executable will disappear - the issue is where to place the configuration support files and the mechanisms to support variants, as you and others require. As for planning, umm, what planning? :-) This is being discussed in order to make a plan but the main hindrance is just how multiarch will actually work. Without the detail of the multiarch implementation, we can't really make a detailed plan for dpkg-cross itself. However, I feel that the cross-config.$arch and associated archtable.d/ support is orthogonal to what actually happens to dpkg-cross and multiarch. The two issues both need to be resolved but the detailed implementation of dpkg-cross within a multiarch capable dpkg will need to work with a realistic multiarch implementation *and* a working implementation of the cross-config and archtable.d/ support. So, in some ways, we can discuss and plan elements of such support in advance of a detailed plan for multiarch itself. > > 1. Do you need to alter ostable, archtable and tripletable or can we > > arrange a method to host all three in one file/directory? Combining the > > tables requires an element of rigour to the definitions and should > > prevent overlaps or omissions. > > I need to alter ostable and triplettable for the arm-uclibc builds. > I also don't really mind how that is done, but it makes sense to me > that whatever mechanism we choose should be basically similar to what > dpkg currently uses. ie. I should be able to create 'unofficial' archs > of my own on demand, but those same definitions should also be able to > be moved to dpkg later should this become an 'official' arch, without > any visible difference to the tools using it. OK. > I think we worked out a basic form for how the triplets should be composed > previously that would work 'universally'. We'd definitely want to shake > that down again and provide it as a guidance for people customising this. A Wiki page would be suitable, linked from http://wiki.debian.org/dpkg and http://wiki.debian.org/Embedded_Debian. > > 2. Do you need dpkg to support this directly or will support via other > > tools be sufficient? (i.e. as now with archtable and dpkg-cross). If > > so, which tools? (bearing in mind that dpkg-cross itself will > > disappear). > > Basically, I need `dpkg-architecture -a $myarch` and dpkg-buildpackage -a > to work as if $myarch were a 'real' arch in the os/triplet tables. That's the crux of the problem. The current method relies on you querying the architecture values via a wrapper like dpkg-cross or a script using libdebian-dpkgcross-perl. To handle this inside dpkg-architecture will need the .d/ directory to be supported by dpkg directly. > We may want to set up some sort of 'registrar', where people can publish > names that are in use, to avoid accidental conflicts, but that could be > as simple as a wiki page that people can update with the names they are > using. I don't expect that will be a huge problem in the near future, > but as more people do this there may be value in something like that. > (in the same sense that wnpp helps people avoid conflicting package > names for works in progress) Agreed. A Wiki page is probably a good start - scripts to parse the various values can be written later. > > > While we may provide > > > one or more of them for general use, specialised devices are each going > > > to want to enable or disable different (sometimes incompatible) features. > > > > To do so, you may well need to also modify the cross-config.cache > > values as these provide the results of macros run by autoconf based on > > a standard Debian system. If uClibc or any other variant changes the > > behaviour of functions compared to standard glibc and standard Debian, > > the variant would also need to take account of these changes. > > Yes, that's something that people defining a 'new arch' would also need to > take care of. So far the things I need don't depend too heavily on that, > but you couldn't build all of the packages in the distro without it. > Unless I'm missing something this should work without changes though, since > you have a unique triplet for each new arch. It's just a part of the cross > environment you need to bootstrap when kicking off a new arch variant. Yes, although care will be needed to prevent unnecessary duplication if the cross-config.cache file needs modification for particular architecture-variants. > > > The only thing I need to keep tweaking is to add: > > > > > > ostable: > > > uclibc-linux linux-uclibc linux[^-]*-uclibc > > > > > > triplettable: > > > uclibc-linux-<cpu> uclibc-<cpu> > > > > > > ... every time I update dpkg and they get overwritten again. > > > > OK, so which executables and which routines need to call these values - > > would support inside dpkg-cross be sufficient or are you seeking for > > dpkg to support /etc/dpkg/arch.d/ instead? > > I had been presuming dpkg would subsume this when/as dpkg-cross vanishes. Guillem's comments about this have an impact here: > "The autoconf config.cache failes are not really specific to dpkg, so > it might make more sense to provide them somewhere else." That is why I think some kind of configuration package will replace dpkg-cross itself. There are various things such a package could do - from assisting in toolchain issues to merely hosting /etc/foo/arch.d/ and we can make some decisions about how this new package would work in advance of multiarch support in dpkg. > > Most of the support you need does exist but it sounds like it needs to > > be optimised. There is no need to alter /usr/share/dpkg/ostable > > or /usr/share/dpkg/tripletable anymore - that support should be > > possible via /etc/dpkg-cross/archtable.d/ and if that isn't working, I > > would appreciate a patch to get it working. > > Ok, we should probably catch up on IRC again and shake out some of these > details. I'm not sure how how dpkg-cross/archtable.d/ fits in with > dpkg-cross going away, but it sounds like that's the next thing I should > get straight in my head and have a play with. I suspect that /etc/dpkg-cross/archtable.d/ itself can migrate into some other package but I do think that dpkg-architecture should support adding whatever values are listed in such a directory. Guillem? Will you be at DebConf9 Ron? I've a feeling that this can be thrashed out much more effectively face-to-face than over IRC. Alternatively, what about a dpkg/embedded_debian/multiarch meeting in Extremadura later in the year where we can thrash out the entire system? -- Neil Williams ============= http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/
Attachment:
pgpk4RRfwj7wg.pgp
Description: PGP signature