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

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: pgpnzgrFrEiRn.pgp
Description: PGP signature


Reply to: