Re: New `dpkg --print-subarchitecture' option
On Thu, 21 Sep 2000, Marcus Brinkmann wrote:
> Thanks for the explanations. In my opinion, they strengthen my point that
> this should not be part of dpkg.
Fair enough. Though I feel, then, that there are other scripts in error,
as `dpkg --print-installation-architecture' seems a fairly common way
to determine the architecture!
> 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.
Yes, this seems ostensibly true, but does anyone know, then, why dpkg
contains a whole family of functions to determine the architecture (e.g.
by invoking gcc!)? They don't seem to be related to package management
at all, either!
> 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.
Hang on, I don't think I understand what you mean.
That excerpt was from /etc/init.d/hwclock. hwclock /does/ work fine on
some ARM platforms, but on Acorn hardware, it needs an extra option,
`--usei2cbus' to be specified. We can't delete `hwclock' from the ARM
.deb of util-linux, because many people want to use it; equally, we can't
run `hwclock' on kernel 2.2 on Acorn hardware, because it will freeze the
kernel! (My example fragment actually didn't include the code for 2.4,
because I'm not concerning myself with that just yet.)
What are you suggesting exactly?
> 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.
I strongly disagree here: `uname' will spit out the precise GNU-form
/processor/ in use, e.g. `armv3l', `armv4l', `armv2', `sa110', and so
on. Translating that into a Debian architecture is what dpkg's `archtable'
does -- I don't want to have to re-do the job of `archtable'!
I'm also not keen on that because people may build ARM kernels based on
new processors, which have new `uname' components -- this means that
our script has to be upgraded to work on their system. If they just use
`dpkg --print-installation-architecture', it will feed them back the
information that they /really/ want: the Debian architecture, and it
will work regardless of what bizarre crap they have in their uname.
There are many different ARM-based processors which come under the
Debian architecture `arm' -- when calculating a subarchitecture, what
we first want to know is whether the basic Debian architecture is the
same; not what actual processor we're running on.
> Oh, no. dpkg-architecture is needed to build Debian packages which are
> different on different platforms. So it absolutely belongs into dpkg-dev.
Hang on -- indeed `dpkg-architecture' /does/ belong in `dpkg-dev' -- I
was just saying that a script that needs to be run by lots of things
/shouldn't/ be in `dpkg-dev', and therefore /shouldn't/ be in
`dpkg-architecture' -- I think you were agreeing, though?
> 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.
This isn't actually true: the transformation from the underlying hardware
identification to a subarchitecture string is not as simple as one-to-one.
It's a carefully-balanced choice, based on the needs of several packages,
and to be frank, it's not a system we can impose on RedHat any more than
we can anything else -- it's chosen specifically for Debian; RedHat may
well not want to adopt it.
> 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).
I don't think MAKEDEV /is/ wrong. `dpkg --print-installation-architecture'
is the most reliable way of obtaining the underlying architecture type
that I have found.
Like I said, `uname' contains, in many cases, a processor ID, or even
worse, something different. `config.guess' and `config.sub' translate
these into a more recognisable form; equally, dpkg's `archtable' also
translates these vast collection of processor strings into something
easily-recognisable: a Debian architecture string.
In my opinion, what `dpkg --print-installation-architecture' is telling
you is `what architecture is this Debian system?'. dpkg is probably the
most fundamentally `Debian' tool in the whole distribution, and therefore
there's a good case to say that it is thus uniquely qualified to tell you
what /Debian architecture/ the system is.
This is why I believe that dpkg is also equally qualified in telling you
what the Debian /sub/architecture is, too.
> 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.
Oh right -- I don't know about these?
But nonetheless, this is a different style of problem altogether. The
subarchitecture indicates one thing: what the Debian name for the hardware
you're running on is. There is no scope for the subarchitecture to be
misused or go wrong -- and for the forseeable future, it will only belong
in the ARM port /anyway/.
> > 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.
(I explained why I don't think this is the case above.)
I don't think you can really claim that an (essentially random) label
made up so that some Debian scripts can identify the hardware can be
said to apply anywhere else. /If/ we were to say that it was generic to
Linux, and therefore should be propagated upstream, we'd then have to
include a copy of the detection script with /every/ package that wanted
to use it (just like `config.guess' and `config.sub') -- this is exactly
what I wanted to /avoid/!
> > 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.
I didn't write the bit that uses `dpkg --print-installation-architecture'!
I presume Bdale Garbee is responsible for that.
I actually think it's a good idea having it in dpkg. Consider this:
there are some architectures where one architecture's binaries will
actually run on another (case in point: arm26 binaries run on arm too).
If you were setting up a chroot system, perhaps, if you analyze the
hardware directly, things won't work. If you use a `dpkg' call, then
you can do things like that.
> > Amiga*) model="amiga"; ;;
> > Macintosh*) model="mac"; ;;
> > Motorola*) model="MVME"; ;;
> > *) model="generic"; ;;
> >
> > 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.
No no -- `Amiga*', `Macintosh*', `Motorola*' are generic, because
they're generated by the /kernel/.
The names `amiga', `mac', `MVME' and so on are /invented/ by a /Debian/
script for the purposes of making the /Debian/ update-modules system
work -- those strings don't exist anywhere else.
> I can see your argument. What do you think of a small script
> linux-subarchitecture (or something like this) put in debianutils?
Well, possibly; but is debianutils guaranteed to be installed even
right from the beginning configuration, in the base tarball?
(That seems a reasonable suggestion, thank you.)
> Well, general point taken (although I see little maintenance need, which
> doesn't apply to the using scripts as well). WRT hwclock, see above.
This isn't actually the case. The ARM architecture is gaining new
platforms /all the time/ -- far faster than any other architecture; people
are designing new boards almost on a monthly basis. Thus there will be
a need to update this script actually quite frequently. Keeping several
copies of it up-to-date /will/ end up being a maintainance hassle: people
will do stuff like only see one copy, and they'll get out of sync, etc.
> 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 think it's reasonable to deny, but not on /those/ grounds. I do think
there's a rationale for having this option in dpkg quite specifically,
and while it /could/ go in a separate script in `debianutils', in that
case so should `dpkg --print-architecture',
`dpkg --print-gnu-build-architecture', and
`dpkg --print-installation-architecture'.
I think it's worth examining the rationale for having /those/ options in
dpkg, because I /believe/ that the rationale for my new option is
identical.
c.
Reply to: