Re: New `dpkg --print-subarchitecture' option
On Wed, Sep 20, 2000 at 10:43:13PM +0100, Chris Rutter wrote:
> Ah, right -- sorry, I didn't explain myself well enough.
Thanks for the explanations. In my opinion, they strengthen my point that
this should not be part of dpkg.
> 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.
But dpkg is our package installer, and this is really not related to package
installation at all. So, putting it in dpkg is an arbitrary (and in my
opinion a bad) decision. If you really need a common place for it, it would
be better as a stand alone tool in debianutils.
> 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
Well, there are at least two bugs in this. First, if hwclock doesn't work on
Acorn, the script shouldn't be in the package in the first place.
Second, this is a wrong use of dpkg --print-installation-architecure, IMHO.
The option print-install-arch is the string that dpkg verifies against the
string in the deb file meta information. It should not be used to find out
the architecture of the running system, but uname should be used for that.
> > 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.
Oh, no. dpkg-architecture is needed to build Debian packages which are
different on different platforms. So it absolutely belongs into dpkg-dev.
Your utility has a completely different purpose, and is not related to
packaging at all. It maybe related to Debian, in this case it should be in
debianutils. But I think not even this is the case. The subarchitecture is
the same on all linux systems, so this should not be debian specific.
Someone might want to use a copy of some script on a RH system, and then the
use of a Debian specific tool causes another obstacle.
> * 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.
MAKEDEV is IMO wrong using dpkg's install architecture. Also, it would be a
good idea to make MAKEDEV architecture any (it is linux specific at least).
> * Managing yet another file seems to me too fiddly. <shrug>
You can't imagine how much trouble I had and still have with dpkg
--print-architecture and the Hurd. Kludging semantically different entities
in a single unit is only causing headaches over the long time.
> > 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.
I am not convinced. From the examples you give, it seems to be Linux
specific, not Debian specific.
> For example, the `dpkg --print-installation-architecture' call in MAKEDEV
> isn't going to work on RedHat; equally, this subarchitecture system won't
> either.
That's because you choose to. MAKEDEV can be made to work on RH, so can your
tool.
> 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/.
? I don't see any Debian specific in the above code. Maybe Debian is the
only distribution which has ports for those arches, but this is a weak
argument, which you can loose any time.
> 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!
I can see your argument. What do you think of a small script
linux-subarchitecture (or something like this) put in debianutils?
> 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!
Well, general point taken (although I see little maintenance need, which
doesn't apply to the using scripts as well). WRT hwclock, see above.
> 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.
Sorry, I have to insist that dpkg is IMHO as wrong a place as any random
place (you could put it in bash, for example. bash --print-subarchitecture :)
> I hope I've explained it better now -- sorry for being cryptic before.
Yes, and I hope I could make a constructive suggstion (debianutils) despite
being firm in my objection to dpkg --print-subarchitecture.
Thanks,
Marcus
--
`Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server
Marcus Brinkmann GNU http://www.gnu.org for public PGP Key
Marcus.Brinkmann@ruhr-uni-bochum.de, marcus@gnu.org PGP Key ID 36E7CD09
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ brinkmd@debian.org
Reply to: