arch specific tags

[Justin B Rye]

Holger Levsen wrote:
>> Would there be enough packages using each of these tags to be worth
>> the upkeep? 
> 
> I think so, yes. There are hardware (and therefore arch) specific packages, 

People have answered this: if we're going to use tags that duplicate
the Architecture field then they probably ought to be handled
specially.

One approach nobody's mentioned is that maybe tags logically implied
by other metadata shouldn't be stored as tags at all; instead they
should be generated as virtual tags by tag-processing front-ends.
That way there's no danger of them getting mangled.

> "emulators",

We've got virtualisers and OS-emulators, and we've got hardware
emulators; there's already a hardware::emulation tag for the latter.
For the ones that are arch-emulators (not all of them - see mmx-emu,
nitpic, etc) it would make sense to have at least one extra tag, but
do we need anything more than (let's say) hardware::cpu?

It's a slippery slope towards hardware::arch:pdp-11 - no, seriously:
see "simh"!

> documentation...!

Such as?  gxemul-doc is the only one I can see!

> Think of the "I'm new to $arch" usecase :)

It seems to me there are two use cases here with conflicting
requirements.
a) "I'm actually using Debian/sparc, so I want hardware::sparc to
	mean that there's a version built to run on my machine"
b) "I'm running i386 but emulating sparc, so tagging an emulator as
	hardware::sparc should mean it's a sparc-emulator, built on
	a list of architectures that probably won't include sparc"
-- 
JBR
Ankh kak! (Ancient Egyptian blessing)