Bug#291939: Bug#268377: Bug#291939: Support for arch aliases
On Mon, Jan 24, 2005 at 03:27:04PM +0100, Robert Millan wrote:
> On Mon, Jan 24, 2005 at 02:57:09PM +0100, Guillem Jover wrote:
> > That's exactly what my patch tries to do, but extending the
> > recognised normal arches with some aliases that get expaned and
> > normalized to normal debian archtitectures, the ones the binary
> > tools can and know how to handle.
>
> When Debian was only linux-gnu, one could check DEB_HOST_ARCH for "i386" to do
> something on i386 only. Currently, if you check DEB_*_ARCH for "i386" you're
> implicitly checking for linux-gnu. This is why Marcus Brinkmann came up with
> the dpkg-architecture solution in 1999, which splits DEB_*_ARCH in DEB_*_CPU
> and DEB_*_SYSTEM. My proposal is just a step in this direction.
No, it does not have anything to do with that. Having cpu and system
split to check the build or host system is fine, it's just some
comodity the tools are handing to the maintainer to ease his task.
It's not the same when you have to specify _multiple_ possible target
arches, splitting does not scale.
Also the main concern Marcus had and the only one I think he keeps
today is the confusion some people may have with *_ARCH that <cpu>
imply linux.
To address that in a not drastic way we could make the policy deprecate
<cpu> arch specifiers and start moving to <kernel>-<cpu> for linux.
So we'd use only <cpu> as linux-<cpu> on the binary side, archive and
related tools.
> What you call "normal" debian architectures is just one of the three variables
> that dpkg-architecture can handle (and actualy the less useful one).
It just needs normalization on the linux case and the added
aliases, then it will be as useful as the GNU counterparts on
dpkg-architecture.
regards,
guillem
Reply to: