[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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:

                major=`Major mouse 10` || continue
                if [ "`dpkg --print-subarchitecture`" = "acorn" ]; then
                        makedev rpcmouse c $major 6 $mouse
                        ln -sf rpcmouse mouse
                        $0 $opts busmice
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

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 \
    exit 0

> 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,

> 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

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"; ;;
        echo "/proc/hardware does not exist, assuming general m68k system"

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.




Reply to: