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

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.


Reply to: