Summary: | gentoo should adopt an "architectural hierarchy" - not a list of architectures | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Duraid Madina <duraid> |
Component: | Conceptual/Abstract Ideas | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED CANTFIX | ||
Severity: | normal | ||
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Duraid Madina
2004-03-28 12:49:09 UTC
This isn't really only a portage thing, it would affect some fundamental processes, so I suggest you write a GLEP about this (see http://glep.gentoo.org). Apart from a GLEP++ statement, I don't think it would be wise for Gentoo to bump packages for other architectures (even if they're in the same 32/64 bit environment) unless you're able to test them on those architectures. That's policy and ensures a little QA. I think there are two kinds of QA at stake here: the simple kind: "does this piece of software work?" the Good kind: "is this piece of software written correctly?" I understand that forcing people to test out software is a good thing. But better would be to move towards a world where everything is LP64-clean. That's probably very difficult, so having an LP32/LP64 split is very practical. Then, the only thing one has to do is distinguish software that makes platform assumptions *besides* LP32/LP64 (for example, inline assembly). I think that this would lead to *fewer* problems than simply testing everything piece by piece, since doing that lets all manner of "once-off" hacks creep into Gentoo. Properly flagging software as LP32, LP64 or "arch-specific" would help as software would get a different (and IMHO far more useful) kind of QA: whether or not software that claims or is assumed to be 64-bit clean and portable (one hopes this is or one day will be the vast majority of packages..) actually is. Hmm. Changing of the hierarchy would be glep material as noted in this bug. Beyond that, multi-lib is starting to do something vaguely similar to what you specified (moreso the grouping). Closing till details/specs are handed to us from an accepted glep/-dev ml discussion. |