Re: New `dpkg --print-subarchitecture' option
On Fri, 22 Sep 2000, Marcus Brinkmann wrote:
> > b) be able to remove --installation-architecture code from dpkg
>
> You can't really remove that (I mean, you can, but you need it internally
> anyway, and so having an external interface isn't bad, except you want to
> hide the installation architecture, which seems to be a silly idea, as it is
> hard coded everywhere *currently*. Changing that requires a lot of work and
> careful thinking).
It's not quite that drastic: the `--print-architecture' and
`--print-gnu-build-architecture' options probably /don't/ belong in
dpkg: all dpkg should concern itself with is the Debian architecture
currently in use.
(This is until someone implements a radical new and clever scheme for
dealing with this all, which is not yet.)
The code doesn't have to be zapped from dpkg yet: it can generate a
couple of warnings whenever invoked until, by woody release time, no
one uses it anymore. (This is if we don't invent a new scheme by then.)
> time decisions). Sub arches are a run time issue, and debianutils isn't a
> bad place for that.
Yes, but I think the idea of a general `platform' tool which gives
descriptive names of the hardware which everyone uses is probably a
Good Thing. If in future the standard way of determining the architecture
of the machine running is `dpkg-platform --architecture', for instance,
that seems sane.
It's a trivial matter to have a DPKG_PLATFORM environment variable which
contains an override: this means that you can, at a pinch, do things like
build NFS-root areas for other architectures, for example by doing
something like:
export DPKG_PLATFORM=arm.acorn.riscpc
chroot MAKEDEV ...
But I don't think it's really a problem: in general, nothing but runtime
scripts want to know the platorm name /anyway/.
> You need to explain this. How do you want to use it? If it ever becomes a
> build issue, I agree it should be in dpkg-architecture. But without knowing
> more (and I really would like to hear about plans involving dpkg and
> architectures), I can't tell.
I don't think the runtime platform will really /ever/ be a build issue
ever, so I don't think the code belongs in `dpkg-architecture'.
My suggestion is to have a tool, `dpkg-platform', which spits out
canonical platform names -- and that's it. You can move the code for
`--print-architecture' (using gcc) and `--print-gnu-build-architecture'
into this new tool, and make everyone move across. Problem solved.
c.
Reply to: