Re: New `dpkg --print-subarchitecture' option
Previously Marcus Brinkmann wrote:
> 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).
I can cheat and share the code, or make dpkg call dpkg-arch. Generally
I would like to move all query things like this to a seperate tool,
and maybe end of with dpkg being a wrappers are those (like gcc).
> > c) have everything in a single place
>
> Doing this just so that it is in a single place is unhelpful, we had this
> situation (with the single place being dpkg). There are different purposes,
> and those should be watched. For example, installation-architecture sits
> perfectly in dpkg. dpkg-architecture fits perfectly in dpkg-dev (compile
> time decisions). Sub arches are a run time issue, and debianutils isn't a
> bad place for that.
I'ld like dpkg-arch to be a runtime thing, sort of like config.guess I
guess. update-modules, makedev and hwclock have shown that that can be
useful. dpkg-architecture works great for compile-time decisions indeed.
Naming might become a bit confusing though..
> 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.
Read your own proposal (I sure hope I didn't grossly misremember what
you wrote in there. I need to write something about planned changes in
dpkg I think to clarify things).
Wichert.
--
________________________________________________________________
/ Generally uninteresting signature - ignore at your convenience \
| wichert@liacs.nl http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Reply to: