http://archives.gentoo.org/gentoo-dev/msg_6d0c9c4226e3b37001e760a8d92a69e7.xml What is needed is to tweak the tools for such a move- specifically adding a new command to the update machinery (profiles/updates). Something roughly like usemove [atom] original_flag new_flag zmedico: What
Petteri, is that bug in the right category? Don't we just need changes in portage?
(In reply to comment #1) > Petteri, is that bug in the right category? Don't we just need changes in > portage? I don't see why this would be Portage specific. Developers need to be modifying files covered by PMS.
No, that wasn't what I meant. In my languageit is defined as "portage == package-manager", which reflects my limited usage of others. My question was more, why does it need to be related to an EAPI? To me it seems to be more PM internals specific. In summary, I'd like to speed up the realization and inclusion.
The format of updates is covered by PMS.
(In reply to comment #3) > No, that wasn't what I meant. In my languageit is defined as "portage == > package-manager", which reflects my limited usage of others. > My question was more, why does it need to be related to an EAPI? To me it seems > to be more PM internals specific. > It's a file that developers update. Ideally the file would behave identically across all package managers.
So whom do I have to talk to to speed things up here?
You need a design that everyone likes, then you need an implementation in Portage. Having said that, moves are bad. We shouldn't be making things even worse than they already are.
No progress since 8 years. Is anyone still interested in this feature? Otherwise, I shall close this bug.
This would be extremely hard to do. Besides needing some kind of alias logic to keep pkg_* phases of binpkgs/vdb working, there is a problem of USE dependencies. I don't think this would really work fine as global moves. For per-package moves, it could result in breaking '[foo?]' kind of USE-deps — we would probably have to introduce flag mapping syntax first.
Closing per comment 8 and comment 9.