Bug#291939: Bug#268377: Bug#291939: Support for arch aliases
On Mon, Jan 24, 2005 at 05:08:58PM +0100, Guillem Jover wrote:
> >
> > 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.
Yes, but you insist in merging it in one field, while adding hacks that
break the debian/control syntax in order to keep mixed two concepts that are
actualy unrelated.
> It's not the same when you have to specify _multiple_ possible target
> arches, splitting does not scale.
You said this before. You claim it doesn't scale because we don't support
an hypothetical example that is in fact a violation of Policy 5.6.7 (footnote
28). I repeat my answer: find an example of a real package that fits in
this category.
> 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.
I really doubt he'd recommend use of a single data field for two orthogonal
pieces of information. But we're both speculating here.
> 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.
This was already proposed (in bug #263743). Scott James and Martin Michlmayr
objected to it, and both suggested a split of the "Architecture" field, which
happens to be what I proposed back in #118910.
> > 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,
Before you said it's the "normal" variable as if the other two (which are
actualy more useful) were not correct. But if it needs "normalization" it
might not be as correct as you pretended. And if such normalization was
already attempted (see bug #263743) and utterly rejected, why should we keep
insisting on it?
We have already variables that are standarised and consistent. These are
DEB_*_CPU and DEB_*_SYSTEM. We've used them for everything except
debian/control. So far nobody objected to them because they're clean and
simple. My point is just to use them for debian/control too.
--
.''`. Proudly running Debian GNU/kFreeBSD unstable/unreleased (on UFS2+S)
: :' :
`. `' http://www.debian.org/ports/kfreebsd-gnu
`-
Reply to: