Let's say that I have a semi-autogenerated repository of hacked packages. Shortly saying, I run a script, it takes a few packages from gx86, patches them and puts in a repo. Due to the semi-automatic nature of the repo generation, there is some delay between a new ebuild being committed to gx86 and the same ebuild being copied and patched in the repo. If someone syncs during that delay, portage will want to install the newer, non-patched version from gx86. Therefore, I ask: could you please provide a way to let a repository force its own packages even if other repositories provide newer versions? I'm thinking of a layout.conf key. If that key/feature is enabled, during dependency resolution emerge would look up all the repos having it for matching $PN. If any of them has that $PN, emerge would only use the 'highest priority' repo having it. Otherwise, it will use the regular version comparison. Example: repo A [highest prio, switch enabled] - app-misc/foo-1 repo B [middle prio, switch enabled] - app-misc/foo-2 repo C [middle prio, switch disabled] - dev-libs/libfoo-1 repo D [lowest prio, switch disabled] - app-misc/foo-3 - dev-libs/libfoo-2 When user asks for app-misc/foo, portage will notice that repos A & B enforce repo priorities and have app-misc/foo. Therefore, only repo with the highest priority (repo A) will be considered. When user asks for dev-libs/libfoo, portage will use the regular lookup since repos A & B don't have that package. Repo D will be used due to highest $PV. What are your thoughts? I think the progress overlay could benefit from this one too.
You can get similar behavior for specific packages by adding atom::repo to your world file. It seems like giving this kind of privilege to repos could be unwanted, but I suppose the user could always override it with /etc/portage/repos.conf.
(In reply to comment #1) > You can get similar behavior for specific packages by adding atom::repo to > your world file. That would require keeping track of those packages, and having them all in @world. > It seems like giving this kind of privilege to repos could be unwanted, but > I suppose the user could always override it with /etc/portage/repos.conf. Yes, it could. I don't mind big fat warnings or something like that. Preferably the explicit ACK on layman's side would be good.
In Progress Overlay it is possible to use repository dependencies with REPOSITORY variable (e.g. RDEPEND="dev-libs/something::${REPOSITORY}").
(In reply to comment #3) > In Progress Overlay it is possible to use repository dependencies with > REPOSITORY variable (e.g. RDEPEND="dev-libs/something::${REPOSITORY}"). That doesn't help when a leaf package gets upgraded to ::gentoo.
