Re: New `dpkg --print-subarchitecture' option
Hi Chris,
On Thu, Sep 21, 2000 at 12:30:53AM +0100, Chris Rutter wrote:
> 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!
Well, there are worse things, and print-installation-architecture is still
quite reliable (in other words: it is slightly incorrect to use it,
semantically, but it works syntactically). It would be hard for me to come
up with a realistical example where it would fail (although my intuition
says it is not impossible).
> > 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!
Right! I asked Wichert several times to remove the plethora of unreliable
functions, and he seems to agree (judging from his reply to your mail). They
are historic baggage, and obsolete since I wrote dpkg-architecture.
> > 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.
Rightly so, I was confused, sorry.
> 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.)
Sorry, I didn't pay attention for a short time span. You are correct, it is
an inconvenient situation. Debian just doesn't handle subarchitectures
gracefully. The Debian arch handling is very limited, and there are more
flexible setups (treating arch features as virtual packages, providing an
interface, like libraries). I am afraid that I don't see a better solution
for the ARM hwclock problem (beside fixing the bug :).
> > 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.
You have a point here. OTOH, it really depends on the exact semantics. In
some situations, making a decision on the type of CPU might be more correct
than basing the decision on the debian arch. (Hey, isn't this exactly why
you need subarchs? Seems I got the curve back to the topic :)
Anyway, I am happy to just drop the discussion of dpkg
--print-installation-architecture and bless all those uses of it you
mentioned (at least until I have some good counterexamples, which I just
don't have right now). So let's talk about subarchitectures ;)
> > 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?
Yes, I agree. I thought you were trying to justify the relation of
subarchitectures to dpkg.
> > 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.
However, we don't need to make it any harder than it is.
(One way is to keep the mapping local to the script, although I understand
the maintenance problem you pointed out)
> > 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.
[I am giving in, as above]
> In my opinion, what `dpkg --print-installation-architecture' is telling
> you is `what architecture is this Debian system?'.
<sidenote>
One of the problems is that there is no real definition for the dpkg
arhcitecture queries (my best example is --print-architecture, where nobody
could tell me what its value should be on the hurd). I think of dpkg
--print-installation-architecture as the string that is matched with the
Architecture string in a package for installation. Both, your and my
interpretation are equivalent now. But what happens when we extend the
architecture features (by allowing linux packages to be installed on the
Hurd and BSD ports, which have emulation, or by allowing pentium optimized
packages?). That's a can of worms :)
</sidenote>
> 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.
Let me agree so far.
> This is why I believe that dpkg is also equally qualified in telling you
> what the Debian /sub/architecture is, too.
Let me disagree here. The subarchitecture is not relevant for package
management at all.
> > 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/.
Both reasons, that it is a different style of problem (I agree) and that it
is local to the ARM port (I can't tell, but I believe you), speak against
inclusion in dpkg, where it sets an interface in stone we will have to live
with for a long time.
> > > 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/!
I agree as far as the installation architecture is concerned.
For the subarchitecture, Debian has not yet applied some label.
In the one example you referred to /proc (and said that this example is
essentially what you want to implement).
I thought the content of /proc/ is defined by the linux kernel crew?
> > > 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.
We are far from a feature like that, and I can guarantee you that a short
seighted attempt that only catches subarches/arches relationships will not
carry as far as it would be desireable.
For details of a more complete solution, see
http://master.debian.org/~brinkmd/arch-handling.txt
I am happy to discuss such issues, but I think for this particular issue it
is more fruitful to limit the scope to the problem you raised (which is
already interesting in its own right).
> > > 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.
Yep. That's why I think that those labels (and the mapping) should be local
to the script that depends on them. But as I said, I am not really against a
Debian specific script and Debian specific labels, for example in
debianutils (for installation scripts a portable solution is not needed
anyway).
> > 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?
Yes, debianutils is flagged essential.
> (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.
I would be interested in hearing your expert opinion on my arch-handling
proposal with a special consideration of sub-arches, where I don't have much
knowledge.
> > 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'.
Well, perhaps it helps if I say that my radical view of point is that all
architecture options except install-architecture should be removed from
dpkg, on the same grounds as subarchitecture should not be in dpkg :)
[I would have to agree with you if I had the opinion that gnu-build etc
should be in dpkg.]
> 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.
I agree. So, it seems that our disagreement is not in the reasoning, but
only in the very first assumptions, and a result of two errors I made
(misunderstanding the hwclock situation, and, worse, exaggerating the
"abuse" of --print-installation-architecture).
Eeek, my mail is far too long, but I hope it is an interesting read
nevertheless, and, as I said, your (and other peoples) opinion on
arch-handling would be much appreciated.
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: