I just have to raise a red flag here.
Oh, man. This is going to be a royal pain for somebody, and I'm not sure
who. In short, Qubes are shipping with architecture numbers that are
inconsistant with RPM's.
The Qubes shipped by Cobalt Micro have RPM 2.4.10glibc shipping on them:
Name : rpm Distribution: (none)
Version : 2.4.10 Vendor: (none)
Release : 1glibc Build Date: Sun Dec 14
Install date: Tue Feb 22 03:10:44 2000 Build Host: duplo.cobaltmicro.com
Group : Utilities/System Source RPM:
Size : 519375
The architecture of these is actually little endian (mipsel), but the
architecture of the packages installed and produced is #4 according to its
rpmrc. At that point 4 was called just plain 'mips', and didn't
diffrentiate the byte order.
A while back we produced the big endian mips (mipseb) architecture for
machines such as SGIs. This was especially important because of the SGI
port actively releasing binaries only in RPM format.
Because (we thought) there were more packages that were in fact more big
endian labelled as 'mips', we kept 4 as mipseb, and made a new mipsel
(#11). I suggested that because I thought the only mipseb/mipsel packages
were produced by specific people: Ralf, Alan and myself. I just hadn't
thought about Cobalt, and nobody at Cobalt piped up to complain when we
were throwing the idea around.
The earlier we solve this problem, the better. The longer we wait, the
more mislabelled packages will be out there. As it is, there will be a
chunk of compiled RPMs for mipseb in /contrib tonight.
So, now we're faced with a dilemna. We need to choose:
1. Rename all the mipseb packages to a new number, let the Cobalt folks
keep #4 as mipsel, and mark #11 as something like 'mips_obselete'. I
don't mind doing this, but I'd like to know this before I start on the
next port of RH source RPMs. There's a lot more Cobalt Micro Qubes out
there than SGI/Linux boxes. I would personally be a bit of an unhappy
camper if this were the case.
2. Get Cobalt Micro from now on to ship their Qube's with the correctly
labelled packages as #11. That would mean Cobalt would have to conform to
our standard. The build date on that box is Dec. 14, before we set the
new standard. I'm surprised they didn't double check that they were using
the correct new architecture number.
3. Go through hell, with all 'rpm -i
ftp.redhat.com/pub/contrib/hurricane/mipseb/bleah.rpm' not reporting
errors on the Qube, despite the incorrect binaries being installed, and
rpm on the Qube building incorrectly labelled binaries.
It would be really good if someone from Qube could give a comment on this.
Anyone know who's doing distribution development stuff at Qube?