Dpkg architectures
What do you think about that idea of changing how dpkg uses architectures?
The architectures like i386, mips, alpha would be the top level
architectures. They would have sub-classes like linux-i386 and hurd-i386.
A higher level architecture would be compatible with systems of its
sub-classes.
In addition there could be architectures like linux-all which means that the
package is common for all Linux systems. The specifier all would match any
system whatever.
So a system running on linux-i386 could install packages of the architectures
linux-i386, i386, linux-all and all and a system running on hurd-i386 could
install
packages of the architectures hurd-i386, i386, hurd-all and all.
I think this system is mostly compatible with the current situation. The only
problems I have found is that a Hurd system would think current Linux packages
are compatible with it and the current Linux/i386 systems would think
linux-i386 packages
are incompatible with it.
I don't know much about the real implementation of the architecture system
so there
could be inconsistencies here.
How difficult it is to implement a system like this? Are there
better solutions to classify packages of different systems?
What are the package pools I have read about on this mailing list?
Reply to: