Re: dpkg-architecture and dpkg-cross
On Fri, Aug 24, 2007 at 10:15:48PM +0100, Neil Williams wrote:
> Can dpkg-cross 2.0.0 migrate wholesale to the dpkg-architecture values?
I think that's the right direction to head in, but I'm not sure
what it will break if we do it right now for all of them.
> Do we drop the unknown values or retain them?
If we keep them, we'll have to keep adding to them, and I'm not
sure the current names are all really consistent with the pattern
anyhow... if win32-i386 -> win32-cygwin, what would we call a
win32-mingw port? Probably better to remove them, and make dpkg
more easily extensible for local additions. More on that below.
> I expect the dpkg-buildpackage and dpkg-shlibdeps diversions to be
> removable in dpkg-cross 2.x and I am working with the dpkg developers
> to achieve this. I would expect this to require a closer tie in with
> dpkg-architecture such that %archtable is completely removed. Yes?
I think this is achievable and the right place to do it. Lower level
tools than dpkg-cross also need to know about these mappings for this
all to work transparently. The discussion on #emdebian about uclibc
naming revealed that we probably need more than one uclibc type in
practice (think mmu and no-mmu just for starters), and there are
clearly more locally desirable variants than we would ever want to
make 'official'. So this needs to be easily extensible to support
experimental and 'fringe' arch definitions imported locally.
The best answer to that so far would seem to be to support local
definitions in cputable.*, ostable.*, triplettable.* files. Then
the cross tools for a custom arch can just install those files,
and dpkg/dpkg-cross etc. will all automatically know how to treat
that arch definition. If we do that, then the extra archs from
dpkg-cross could just be moved to *table.dpkg-cross (provided by
dpkg-cross.deb) for as long as they still are needed, and everything
that needs to will actually recognise them.
The dpkg maintainers might know a better way to do this, but it
seems like a common and fairly safe mechanism to allow additional
configuration to be supplied by the local admin or an external
package when required.
Cheers,
Ron
Reply to: