[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Merging dpkg-cross into the dpkg source

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.


> 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
> 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

> > > 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

Attachment: pgpnzgrFrEiRn.pgp
Description: PGP signature

Reply to: