Re: New `dpkg --print-subarchitecture' option
On Wed, 20 Sep 2000, Marcus Brinkmann wrote:
> > There are a reasonable number of utilities (update-modules, X
> > configuration, hwclock) that need to know more than just the processor
> > architecture that they're running on -- they need the type of hardware
> > as well (e.g. m68k does this).
>
> I don't know for sure, but can't they adapt at run time? The debian
> architecture is meant for a decision on recompilation, so if they are the
> same Debian port ("alpha", "m68k"), there is no need for dpkg to know
> anything about it.
Ah, right -- sorry, I didn't explain myself well enough.
This is /purely/ a runtime-adaption issue, as it's independent of the
architecture itself. For instance, `MAKEDEV' will contain a fragment
like this:
arm-mice)
major=`Major mouse 10` || continue
if [ "`dpkg --print-subarchitecture`" = "acorn" ]; then
makedev rpcmouse c $major 6 $mouse
ln -sf rpcmouse mouse
else
$0 $opts busmice
fi
;;
and update-modules would contain something like this:
model="`dpkg --print-subarchitecture`"
which it would use to select the right module aliases for the particular
hardware.
As another example, /etc/init.d/hwclock might do this:
if [ "`dpkg --print-installation-architecture`" = "arm" -a \
"`dpkg --print-subarchitecture`" = "acorn" ]; then
echo "hwclock does not work on Acorn hardware yet -- please remove this \
package";
exit 0
fi
> This said, this feature doesn't belong in dpkg at all. If there is a need
> for a compile time position with Debian packages, it belongs in
> dpkg-architecture.
Right; well, it's not compile-related /at all/ -- no compile should ever
do anything specific to the machine it's being built on!
> But then, I am afraid you are not really talking about compile time
> decisions that are relevant for package building. In this case I must
> ask not to add this to dpkg as it doesn't make sense.
Right, well, I hope I've at least cleared things up a little. Here's
reasons why I think it /could/ be in dpkg:
* `dpkg-architecture' is in `dpkg-dev' -- this is a far more fundamental
utility which needs to be present during early configuration of the
Debian system.
* It is, I think, really a sort of parallel option to
`--print-installation-architecture' -- it's finding out something
fundamental about the machine: note that MAKEDEV actually uses
`dpkg --print-installation-architecture' to determine what devices to
install, for instance.
* Managing yet another file seems to me too fiddly. <shrug>
> Do you really need another tool? Can uname provide this information?
No -- the uname doesn't contain information about the hardware, really;
only the architecture (`arm', `armv3l', `armv4l', and very occasionally,
`sa110').
> If not, then there is probably no portable way to determine the
> subarchitecture, and I suggest to include the small snippet of code that
> parses /proc/whatever in each package, so it is clear that this is
> not portable, and protect it with #ifdef LINUX everywhere.
Well, this whole system is /completely/ non-portable: it's specific only
to Debian and Debian-specific scripts.
For example, the `dpkg --print-installation-architecture' call in MAKEDEV
isn't going to work on RedHat; equally, this subarchitecture system won't
either.
Take a look at this fragment from update-modules for m68k:
if [ $arch = "m68k" ]; then
if [ -f /proc/hardware ]; then
model=`cat /proc/hardware | sed -ne 's/^Model:[[:space:]]*//p'`
case $model in
Atari*) model="atari"; ;;
Amiga*) model="amiga"; ;;
Macintosh*) model="mac"; ;;
Motorola*) model="MVME"; ;;
*) model="generic"; ;;
esac
model=".${model}"
else
echo "/proc/hardware does not exist, assuming general m68k system"
fi
The names `atari', `amiga', `mac' and so on are only meaningful to
Debian /anyway/.
Basically I want a system which achieves the same effect as that shell
fragment above, except I don't want to have to repeat it in several
different files!
The ARM architecture probably has the widest and most different variety
of hardware available: this means that ARM is particularly hard-hit for
needing to work out what the hardware it's running on is; for instance,
`hwclock' /must not/ be run on one subarchitecture -- I don't fancy cut-
and-pasting the fragment into /etc/init.d/hwclock and remembering to
keep it up-to-date!
I'm not /sure/ that this is by any means the best way of doing it -- but
it seems to be more-or-less okay.
I hope I've explained it better now -- sorry for being cryptic before.
Thanks,
c.
Reply to: