Debian bugs or normal behaviour?
Hi!
Mine was the sparc clone (a Hamilton Hamstation, sun4m), Dalibor Topic
mentioned in his Howto posted on the list this week. So I'm also a
fresh Debian on Sparc lover... :-)
A few things looked strange to me:
We, well in fact Dali :-), initially installed Woody with Kernel
2.2.20.
1) dpkg --print-architecture and similar options returned "sparc-none"
which led to some dpkg warnings about not finding the architecture
in the remapping table. After installing 2.4.21 (from sarge), this
output moved to "sparc" and everything seems fine now, regarding
this issue. Just wondered about where it may come from. The tip
with upgrading to Kernel 2.4.x came from #debian on the freenode
IRC net, where they pointed me to the appropriate problems on x86
("i386-none" not found in remapping table, see
http://lists.debian.org/debian-user/2002/debian-user-200201/msg02151.html)
2) When I first started up dselect, one of the first packages marked
as "new" and "to be installed" was the "required" base package
"libc6-sparc64":
,------------------------------------------------------------------------------------------------------------
| n* Req base libc6-sparc64 <none> 2.2.5-11.2 GNU C Library: 64bit Shared libraries for UltraSPARC
'------------------------------------------------------------------------------------------------------------
This looks to me like a bug in the package since this package seems
only be useable on sun4u (UltraSparc) while the distribution also
targets sun4[cdm] (non-ultra Sparcs), which are 32 bits.
But due to not yet being that deep with Sparc hardware (although I
lived with them for quite a lot of years at university, which is
also the reason why I wanted my own Sparc ;-), I'm not sure, if a)
this package can be installed with no risk or problems on 32-bit
Sparc or b) 64-bit Sparcs will run without it.
As far as I know the debian package format, it seems to me that
there is no obvious way to mark packages only as required if there
is a special subarchitecture present. But on the other hand the
actual kind of package handling could lead to problems, if someone
doesn't check the list of to be installed packages carefully, if
they fit for his or her subarchitecture.
Any comments on this issues? Haven't found anything in the archive
yet...
Regards, Axel
--
Axel Beckert - abe@deuxchevaux.org - http://abe.home.pages.de/
Reply to: