The following suggestion might be useful for users who run two different architectures. The main example is probably amd64 with an x86 chroot, but perhaps people with several systems (or e.g. linux + bsd) might have similar problems: Especially for amd64/x86 it happens often (currently >60 packages) that one version of a package is already stable on x86 while it is still ~amd64 (or vice versa) although in practically all cases the version works on both arches. Usually, the delay between stabilization is not very large, but anyway after a new emerge --sync the stable versions are usually never in sync for both arches. The problem with this is that without manual unmasking it would be necessary to download/keep two different tarballs (and in case of a chroot it is strange anyway to have a different version installed). I think the "clean" solution to this problem would be if one could advice portage to install packages which are stable on at least one of these architectures. However, ACCEPTED_KEYWORDS='amd64 x86' is not a good idea, since this will also accept packages on the amd64 system which are x86-only or vice versa. Hence, I suggest to enhance the syntax and allow e.g. something like ACCEPTED_KEYWORDS='amd64 x86&~amd64' (on the amd64 system) ACCEPTED_KEYWORSD='x86 ~x86&amd64' (on the x86 chroot) where "&" means that both keywords must match.
Anyone likes this idea? I for sure don't.
Yeah, this is....icky, to say the least.
I guess you both don't run parallel amd64 + x86 systems (or you have no download limitations and can afford downloading most things twice).
I think the right solution to this problem is to sync the keywords in the ebuild, not to increase the complexity in the manager configuration.
(In reply to comment #4) > I think the right solution to this problem is to sync the keywords in the > ebuild, not to increase the complexity in the manager configuration. Maybe there was a misunderstanding: I am not talking about *the* ebuild (i.e. /etc/portage/package.keywords); I am talking about ~50-200 ebuilds - number and names vary at every sync. Moreover, automatically changing keywords by a script after emerge --sync is no good solution either: In case of problems, one wants to know of course whether ebuild is ~amd64 or amd64. In forums, I have also talked with members of amd64 team. They cannot solve the problem either (of course): understandably, before something is marked stable on amd64, they want that it is thoroughly tested on amd64 and not only on x86. So any automatism modifying the keywords itself would be bad. So it is in its nature a *configuration* request: It is really up to the user to say if he wants a system which is "in between" amd64 and ~amd64 (such that it matches his other systems or chroot without manually modifying configuration for each package individually after every think): If the user can say "amd64" and "~amd64" and actually even the strange "amd64 x86" why shouldn't he be allowed to say the more natural "~amd64&x86"? It really is not a complex configuration.
(In reply to comment #5) > (In reply to comment #4) > > I think the right solution to this problem is to sync the keywords in the > > ebuild, not to increase the complexity in the manager configuration. > > Maybe there was a misunderstanding: I am not talking about *the* ebuild (i.e. > /etc/portage/package.keywords); I am talking about ~50-200 ebuilds - number > and names vary at every sync. Yes, I was talking about "the ebuild" in the general sense. > Moreover, automatically changing keywords by a script after emerge --sync is > no good solution either: In case of problems, one wants to know of course > whether ebuild is ~amd64 or amd64. That wasn't what I meant. > In forums, I have also talked with members of amd64 > team. They cannot solve the problem either (of course): understandably, before > something is marked stable on amd64, they want that it is thoroughly tested on > amd64 and not only on x86. So any automatism modifying the keywords itself > would be bad. I wasn't talking about automatisms at all. I meant that the workflow should be improved, so that ideally arch teams stabilize a package at the same time instead of bit by bit. Yes, that's quite a change to how things are done today. > So it is in its nature a *configuration* request: It is really up to the user > to say if he wants a system which is "in between" amd64 and ~amd64. And it depends on us if we want to support such things, and so far I haven't seen any support for the idea. > If the user can say "amd64" and "~amd64" and actually even the strange "amd64 > x86" why shouldn't he be allowed to say the more natural "~amd64&x86"? It > really is not a complex configuration. Depends on your POV: Currently keyword filtering is a simple containment test, you want to extend it into a complex containment test. Additionally the proposed syntax raises several issues wrt parsing, e.g. what is "x86&-amd64" supposed to mean (ignoring wether that makes sense or not). Not mentioning that it's probably going to break a few things that parse ACCEPT_KEYWORDS on their own. However, I have one good news for you: I plan to reimplement the visibility filtering after 2.2 is released to make it more transparent and configurable, so you might be able to implement a filter with the desired behavior on your own and just configure portage to use that instead of the standard keywords filter.
Thank your for your detailed reply. (In reply to comment #6) > I meant that the workflow should be improved, so that ideally arch teams > stabilize a package at the same time instead of bit by bit. That was my first suggestion, but it appears not realistic: it would probably make "pure" systems more unstable. > However, I have one good news for you: I plan to reimplement the visibility > filtering after 2.2 is released to make it more transparent and configurable Optional hooks are really excellent news. I was actually afraid that portage's direction of development is to cancel more and more configuration options. I am really happy to see that I was wrong.
