Re: Merging dpkg-cross into the dpkg source
On Sun, Feb 22, 2009 at 12:23:22PM +0000, Neil Williams wrote:
> On Fri, 20 Feb 2009 16:08:45 +1030
> Ron <ron@debian.org> wrote:
> > The other issue related to this was some mechanism to permit local
> > definitions to be maintained in ostable and triplettable.
>
> /etc/dpkg-cross/archtable.d/ could be extended for that purpose -
> it's a much better idea than the legacy method of hardcoding such
> variants into dpkg-cross itself. It was originally designed for this
> situation, so if it isn't suitable, it needs to be fixed. See #447427
Ah indeed, that is the very discussion I was referring to here.
> > 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 questions are:
>
> 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.
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.
> 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.
I had already stopped using dpkg-cross for this since we discussed it last
and its diversion of other tools were removed. I have no 'native' packages
to convert, so everything is necessarily being built from source using a
cross toolchain.
But I can build packages like:
busybox-vtcustom-static_1.12.4-1_uclibc-arm.deb
Which can then be unpacked into the target rootfs.
Ultimately that would probably become something more like uclibc_vt-arm,
since our uclibc build is configured to suit exactly the board that it is
targetted for. We'd leave the bare "uclibc-arm" namespace (with no other
qualifiers) as something that an 'official' Debian arch might one day
define (whether it actually does or not), to avoid conflicts with other
users (or even ourselves :) who have alternative uclibc configurations
for other arm processors.
Here again, we'd want to provide a guidance for people to make sensible
use of the namespace, but since it's a local thing, the only people they
will really screw if they mess up is their own users. Nobody else will
ever see their arch or have to work around it.
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)
> Maybe what we shall end up doing is migrating the package conversion
> routines from /usr/bin/dpkg-cross into dpkg|dpkg-dev using multi-arch
> support and implementing the architecture-support configuration of
> dpkg-cross as a configuration package that handles the static data like
> cross-config. $arch, archtable.d/ and the rest in /etc/. The only issue
> for me is about the status of multi-arch in Debian - where are we at?
There was enough of it for me to adapt to dpkg-cross no longer diverting
several tools, but I'm not really sure where the rest of that is going.
> > 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.
> > 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.
> 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.
Best,
Ron
Reply to: