On Wed, Jan 30, 2002 at 11:21:21PM +0100, Michael Weber wrote:
> * Joel Baker <[EMAIL PROTECTED]> [2002-01-30T10:55-0700]:
> > Two or three times now, I've run into bugs that were wishlisted or outright
> > closed because we are not considered an Official Architecture (tm) yet; the
> > determining factor in this appears to be "are you listed in dpkg's arch
> > list?"
>
> Well, and that was mainly the reason why jimmy and me started the
> thread about the config.{guess,sub} issue earlier this week, after
> discussing it briefly on IRC.
>
> The problem AIUI is, you can't arbitrarily choose a name and put it
> into the archtable of dpkg. The first column part has to match the
> canonicalized arch name as produced by config.sub (modulo the
> "unknown" part). Here's a list of the *BSDs, currently in the
> unofficial archtable:
> i386-freebsd freebsd-i386 freebsd-i386
> i386-openbsd2.8 openbsd-i386 i386
> i386-netbsdelf1.5 netbsd-i386 i386
> i386-netbsdelf1.5 netbsd-i386 i386
> alpha-netbsd-debian netbsd-alpha alpha
>
> We need to reach a consensus here (that won't bite us in the future),
> and make sure the config.* guys like it, too, before we ask the dpkg
> maintainers to incorporate the changes. I mentioned some of the
> things to keep in mind in the "How to check for a GNU userland"
> thread.
I have a similar problem. Basically, I'm using i386-unknown-freebsd4. I patched
config.guess to drop the minor version number. It seemed better than entering
every permutation of i386-unknown-freebsd4.x that I could think of. That's just
asking for problems.
Maybe configure could be modified to support wildcards in the archtable? That
might avoid the need to change either config.* or the archtable regularly. I
can write a patch to do that, if it would be acceptable to the dpkg
maintainers.
A related issue:
I found that some packages (gcc for example) use dpkg-architecture to get the
GNU architecture, and pass it to configure. It seems to work best if I have
dpkg return i386-freebsd4, rather than i386-freebsd or i386-freebsdelf.
> > Therefore, I think it's about time we were. I'm willing to talk to the
> > maintainer about it, but before I start down that road, I need to know
> > what, if any, patches were done to dpkg to get it to work in the tarball...
>
> I started with the patch from
>
> http://debian-bsd.sourceforge.net/dpkg/dpkg-patch
>
> and modified it a bit, so that dpkg now builds smoothly on my machine:
>
> http://people.debian.org/~michaelw/dpkg-bsd.patch
>
> Please note that this is BY NO MEANS a patch that should be submitted
> to the dpkg team! There are some hacks in it, that I didn't come
> around to fix properly.
>
> Also, this version should build ok on a native NetBSD system (modulo
> some minor adjustments to INCLUDE_PATH AND LDFLAGS, and a link from
> curses.h to ncurses.h). If somebody is interested I can probably
> write up a more detailed guide.
Another similar situation... I need to upgrade, and see if the version in CVS
requires less kludging. That python version of dpkg-shlibdeps may solve several
headaches for me.
