Re: [gentoo-dev] gentoo git step by step guide
hasufell: First draft and only the basic ebuild workflow. I'm working out the rest here https://wiki.gentoo.org/wiki/Gentoo_git_workflow#step_by_step_example_.28ebuild.29
[gentoo-dev] Packages up for grabs
Hello! Below are some packages that I fail to take care of as needed and have not been using myself for a while. Please take over whatever you have interest in: Latest Open bugs app-text/xmlstarlet yes no media-libs/libmp3spltyes yes media-sound/mp3splt-gtk yes yes media-sound/mp3splt yes yes dev-python/html2text no/2014.9.8 no dev-python/inotifyx no/0.2.2no games-action/openlierox no/0.59_beta10 no media-gfx/drqueueyes yes media-libs/opencollada no/?yes sys-fs/pytagsfs yes yes Many thanks, Sebastian
[gentoo-dev] Gentoo git workflows and the stabilization/keywording process
Hi! Since we're causing at least mild upheaval process-wise, I thought I'd bring up a topic that will be exacerbated by the git migration if it's not really addressed. AIUI, we try to avoid merge conflicts, unless the merge is a meaningful integration of divergent processes. However, one aspect of how ebuilds are written these days will cause a non-trivial amount of merge commits that are not actually useful in that sense. This is due to the way keywording and stabilization work on an ebuild level. Since keywords are all in one line, any merge tool will barf on two keywords being changed in disparate clones. I.e. if I change ~alpha-alpha while someone else changes ~amd64-amd64, we will have a merge conflict. There several approaches to this problem: 1) Make a merge commit as explained above. Aside from the not really useful merge commit, this also means manual work for the ATs, who could really do with less manual labor. 2) roll back the local commit, fetch and re-do the semantically equivalent commit. This might be automated, but someone has to actually write that code. 3) Do away with one-line KEYWORD lists. This has wide-ranging repercussions, from grepping-and-parsing (which is already broken in different ways[0]), and it makes the preamble of ebuilds longer. The fundamental problem is of course that most diff/merge algorithms are line-oriented. If two commits change the same single line, both CVS and git are unhappy and yell for human intervention. The difference with git is that the commit(s) that introduced the change need to be rolled back and semantically re-applied, whereas CVS just puts conflict markers nto the file for me to sort (extra work, but much less than rollback+hand-merge) and the lets me commit. In essence, the local-vs-remote history discrepancy does not exist with CVS, and in git it requires extra manual work to resolve[1]. In any case, this needs to be addressed in _some_ way. Regards, Tobias [0] Think conditional keywords, like: if something; then KEYWORDS=this else KEYWORDS=that fi This is already in the tree and breaks the grep/scripting assumption, so it's a weak argument. [1] As I mentioned, this extra work is scriptable, but that needs to be done and the process for ATs needs to be amended to explain this situation. -- Sent from aboard the Culture ship GCU (Ridge Class) Jaundiced Outlook
Re: [gentoo-dev] Gentoo git workflows and the stabilization/keywording process
On Thu, 18 Sep 2014, Tobias Klausmann wrote: However, one aspect of how ebuilds are written these days will cause a non-trivial amount of merge commits that are not actually useful in that sense. This is due to the way keywording and stabilization work on an ebuild level. Since keywords are all in one line, any merge tool will barf on two keywords being changed in disparate clones. I.e. if I change ~alpha-alpha while someone else changes ~amd64-amd64, we will have a merge conflict. There several approaches to this problem: 1) Make a merge commit as explained above. Aside from the not really useful merge commit, this also means manual work for the ATs, who could really do with less manual labor. 2) roll back the local commit, fetch and re-do the semantically equivalent commit. This might be automated, but someone has to actually write that code. 3) Do away with one-line KEYWORD lists. This has wide-ranging repercussions, from grepping-and-parsing (which is already broken in different ways[0]), and it makes the preamble of ebuilds longer. If this should really turn out to be a problem, then we could also: 4) Replace git's default merge driver by our own one that is better suited for ebuilds. This can be done per repository via .git/config and .gitattributes. Ulrich pgp6wMLsX3Mtj.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo git workflows and the stabilization/keywording process
On Thu, Sep 18, 2014 at 1:53 PM, Ulrich Mueller u...@gentoo.org wrote: On Thu, 18 Sep 2014, Tobias Klausmann wrote: However, one aspect of how ebuilds are written these days will cause a non-trivial amount of merge commits that are not actually useful in that sense. Git can do merge conflict markers just like cvs. Also, in practice I don't tend to run into merge conflicts with cvs - I always do a directory update before making changes. With git I'd probably not do a pull if I were working on an obscure pacakge, but if I were doing a security keywording I'd certainly do a pull before touching anything since the likelihood of a conflict is much higher. Git even allows the use of tools like meld to resolve conflicts, besides the usual fill-the-file-with-diffs-to-cleanup approach. If this should really turn out to be a problem, then we could also: 4) Replace git's default merge driver by our own one that is better suited for ebuilds. This can be done per repository via .git/config and .gitattributes. Certainly that would be even more helpful! -- Rich
Re: [gentoo-dev] My masterplan for git migration (+ looking for infra to test it)
On Thu, 18 Sep 2014 17:04:55 +1200 Kent Fredric kentfred...@gmail.com wrote: What's more, you can in fact do: git mv foo-1.ebuild foo-2.ebuild git commit and you can still easily tell git to show that as a difference in a log. Example script to emulate this and example output: https://gist.github.com/kentfredric/10e93e9aac875e9edb93 ( In fact, you don't even have to use 'git mv', as long as you change the tree state completely, git is smart enough to track most changes ) Lets assume, that I don't want to scrap old ebuild yet. There's no git cp command. git mv is just git rm + git add. That's what does it look like (usual revbump with git add in reality): https://github.com/cerebrum/dr/commit/311df9b04d876f5847416fe5ba699edfab50adb6 I think that git (at least with default config is a pain in the ass for packages at all and we should probably think about better platform for portage).
Re: [gentoo-dev] My masterplan for git migration (+ looking for infra to test it)
On Thu, Sep 18, 2014 at 3:33 PM, Diamond diam...@hi-net.ru wrote: Lets assume, that I don't want to scrap old ebuild yet. There's no git cp command. git mv is just git rm + git add. That's what does it look like (usual revbump with git add in reality): https://github.com/cerebrum/dr/commit/311df9b04d876f5847416fe5ba699edfab50adb6 I think that git (at least with default config is a pain in the ass for packages at all and we should probably think about better platform for portage). What would you propose? The problem you raise is just as much an issue with cvs. I don't get a continuous history across revbumps in cvs today, so I don't really see a problem with moving to git. -- Rich
[gentoo-dev] Git copy detection (was: My masterplan for git migration...)
On Thu, Sep 18, 2014 at 11:33:40PM +0400, Diamond wrote: Lets assume, that I don't want to scrap old ebuild yet. There's no git cp command. git mv is just git rm + git add. That's what does it look like (usual revbump with git add in reality): https://github.com/cerebrum/dr/commit/311df9b04d876f5847416fe5ba699edfab50adb6 Git can check for copies if you like: $ git clone git://github.com/cerebrum/dr.git $ cd dr/ $ git show --find-copies-harder 311df9b04 commit 311df9b04d876f5847416fe5ba699edfab50adb6 … diff --git a/games-strategy/openra/openra-20140608.ebuild b/games-strategy/openra/openra-20140722.ebuild similarity index 100% copy from games-strategy/openra/openra-20140608.ebuild copy to games-strategy/openra/openra-20140722.ebuild Cheers, Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] My masterplan for git migration (+ looking for infra to test it)
On Thu, 18 Sep 2014 16:00:59 -0400 Rich Freeman ri...@gentoo.org wrote: What would you propose? The problem you raise is just as much an issue with cvs. I don't get a continuous history across revbumps in cvs today, so I don't really see a problem with moving to git. I don't know what to propose. I stumbled over this problem when started to use git for packages. At least there are other SCM systems too. Haven't investigated them yet for that issue. Facebook uses even it's own one.
Re: [gentoo-dev] My masterplan for git migration (+ looking for infra to test it)
Diamond wrote: I stumbled over this problem when started to use git for packages. Use git show -M to unstumble yourself. //Peter
Re: [gentoo-dev] Git copy detection (was: My masterplan for git migration...)
On Thu, 18 Sep 2014 13:08:11 -0700 W. Trevor King wk...@tremily.us wrote: Git can check for copies if you like: $ git clone git://github.com/cerebrum/dr.git $ cd dr/ $ git show --find-copies-harder 311df9b04 … copy from games-strategy/openra/openra-20140608.ebuild copy to games-strategy/openra/openra-20140722.ebuild --find-copies-harder is better but it isn't shown on github in a convenient way for package management.
Re: [gentoo-dev] Git copy detection (was: My masterplan for git migration...)
On Fri, Sep 19, 2014 at 01:01:13AM +0400, Diamond wrote: On Thu, 18 Sep 2014 13:08:11 -0700 W. Trevor King wrote: Git can check for copies if you like: $ git clone git://github.com/cerebrum/dr.git $ cd dr/ $ git show --find-copies-harder 311df9b04 … copy from games-strategy/openra/openra-20140608.ebuild copy to games-strategy/openra/openra-20140722.ebuild --find-copies-harder is better but it isn't shown on github in a convenient way for package management. So Git works great, and GitHub's web UI doesn't support all of Git's bells and whistles, so… switch to a different VCS? Personally, my conclusion is “just use Git from the command line”. It's not like you're abandoning long years of experience using CVSHub with some miracle UI ;). Cheers, Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Git copy detection (was: My masterplan for git migration...)
On Thu, 18 Sep 2014 14:29:41 -0700 W. Trevor King wk...@tremily.us wrote: So Git works great, and GitHub's web UI doesn't support all of Git's bells and whistles, so… switch to a different VCS? Personally, my conclusion is “just use Git from the command line”. It's not like you're abandoning long years of experience using CVSHub with some miracle UI ;). --find-copies-harder For performance reasons, by default, -C option finds copies only if the original file of the copy was modified in the same changeset. This flag makes the command inspect unmodified files as candidates for the source of copy. This is a very expensive operation for large projects, so use it with caution. Giving more than one -C option has the same effect. P.S. As you see from description this option affects git performance. So, we probably can arrive at a conclusion that git itself isn't good at all for package management. Maybe there are better architectural decisions for that.
Re: [gentoo-dev] My masterplan for git migration (+ looking for infra to test it)
On 19 September 2014 07:33, Diamond diam...@hi-net.ru wrote:
Lets assume, that I don't want to scrap old ebuild yet. There's no git
cp command. git mv is just git rm + git add. That's what does it look
like (usual revbump with git add in reality):
https://github.com/cerebrum/dr/commit/311df9b04d876f5847416fe5ba699edfab50adb6
I think that git (at least with default config is a pain in the ass for
packages at all and we should probably think about better platform for
portage).
Not necessarily. It tracks copies too, -C
Also, don't rely on githubs presentation of things as being gospel, its
better than nothing, but it falls short of git.
git log -p --find-copies-harder games-strategy/openra-bin/*.ebuild
You can quite easily convince git to pretend vaguely similar files in the
log are sources of each other with the right options.
Throwing -M1 -C1 in that command will let git find more
Just because I think git cant doesn't mean git cant, especially if
you've not asked how can I do :)
For instance:
git log --stat -C1 -M1 --find-copies-harder
In your repo finds you these interesting copies if you look far enough
.../files/opentracker.init.d =
net-misc/twonky/files/twonky.initd | 40 +--
{www-apps/rutorrent =
net-misc/minidlna}/metadata.xml | 16 ++-
{games-strategy/openra-bin =
dev-util/mono-debugger}/metadata.xml | 8 +--
media-video/{webcamstudio =
webcamstudio-module}/ChangeLog | 42 +
--
Kent
*KENTNL* - https://metacpan.org/author/KENTNL
Re: [gentoo-dev] Git copy detection (was: My masterplan for git migration...)
On 19 September 2014 10:13, Diamond diam...@hi-net.ru wrote: P.S. As you see from description this option affects git performance. So, we probably can arrive at a conclusion that git itself isn't good at all for package management. Maybe there are better architectural decisions for that. Well. Yes. You're doing more because you want to get more out. Or did you expect git to find potential copies from your whole repository for /no/ increase in performance cost? That's why it defaults to off, for performance. ( And because not everyone wants it on by default, because its somewhat a subjective aesthetic choice ) -- Kent *KENTNL* - https://metacpan.org/author/KENTNL
Re: [gentoo-dev] Git copy detection (was: My masterplan for git migration...)
Diamond wrote: we probably can arrive at a conclusion that git itself isn't good at all for package management. I don't think we can. Please stop the nonsense, at least until you have created something superior to git. //Peter
Re: [gentoo-portage-dev] [PATCH] per package environment: generalize the mechanism to be profile specific
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 For future reference, please use git's send-email option with - --in-reply-to, to send the patches inline. The way they are sent now, (I assume) most of us have to download your patches and open them in a text viewer to review it. If the patches were inline, I could just look at them in the email client. Thanks for splitting them up, and thanks for your work on this. - -- Alexander berna...@gentoo.org https://secure.plaimi.net/~alexander -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlQajFsACgkQRtClrXBQc7We4gD/UztD3pvIRr2DDP5l/qZBFPFq zwJ+A2ijpKkBDGAF9kwBAJ8fii7loZ+AHw+InoHQat7s2BOFh6fkvz/uNx2J4iDb =IGeT -END PGP SIGNATURE-
Re: [gentoo-portage-dev] [PATCH] per package environment: generalize the mechanism to be profile specific
Dnia 2014-09-17, o godz. 14:57:10 Bertrand Simonnet bsimon...@google.com napisał(a): I'd rather use the env/ mechanism instead of the package.env one as it is more flexible. It depends on what you aim to do. As portage(5) points out, both have their advantages: - package.env is parsed early, and so allows you override more variables, like FEATURES, - env/ is used as bashrc extension. The other difference is that package.env supports any atom syntax that the particular EAPI supports, while env/ has hardcoded list of possibilities. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-portage-dev] [PATCH] per package environment: generalize the mechanism to be profile specific
For my purpose, I think bash scripting would be more useful. I thought about package.env in the beginning (see first few messages on this thread) as it would help us reuse code but variable setting only will limit what we can do. If you want package.env, we can implement it too and have both mechanisms available. Thanks, Bertrand On Thu, Sep 18, 2014 at 1:02 AM, Michał Górny mgo...@gentoo.org wrote: Dnia 2014-09-17, o godz. 14:57:10 Bertrand Simonnet bsimon...@google.com napisał(a): I'd rather use the env/ mechanism instead of the package.env one as it is more flexible. It depends on what you aim to do. As portage(5) points out, both have their advantages: - package.env is parsed early, and so allows you override more variables, like FEATURES, - env/ is used as bashrc extension. The other difference is that package.env supports any atom syntax that the particular EAPI supports, while env/ has hardcoded list of possibilities. -- Best regards, Michał Górny
[gentoo-portage-dev] [PATCH] _backtrack_depgraph: fix bug #523048
This fixes _backtrack_depgraph to immediately report necessary
REQUIRED_USE changes instead of discarding the graph. This is
accomplished by replacing the depgraph.success_without_autounmask
method with a new need_config_change method that accounts for both
autounmask and REQUIRED_USE changes.
X-Gentoo-Bug: 523048
X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=523048
---
pym/_emerge/depgraph.py | 11 +++
pym/portage/tests/resolver/ResolverPlayground.py | 16 ++--
2 files changed, 21 insertions(+), 6 deletions(-)
diff --git a/pym/_emerge/depgraph.py b/pym/_emerge/depgraph.py
index 6332733..e7ae720 100644
--- a/pym/_emerge/depgraph.py
+++ b/pym/_emerge/depgraph.py
@@ -421,6 +421,7 @@ class _dynamic_depgraph_config(object):
self._buildpkgonly_deps_unsatisfied = False
self._autounmask =
depgraph._frozen_config.myopts.get('--autounmask') != 'n'
self._success_without_autounmask = False
+ self._required_use_unsatisfied = False
self._traverse_ignored_deps = False
self._complete_mode = False
self._slot_operator_deps = {}
@@ -2461,6 +2462,7 @@ class depgraph(object):
self._dynamic_config._unsatisfied_deps_for_display.append(
((pkg.root, atom),
{myparent : dep.parent,
show_req_use : pkg}))
+ self._dynamic_config._required_use_unsatisfied
= True
self._dynamic_config._skip_restart = True
return 0
@@ -8390,8 +8392,9 @@ class depgraph(object):
return self._dynamic_config._need_restart and \
not self._dynamic_config._skip_restart
- def success_without_autounmask(self):
- return self._dynamic_config._success_without_autounmask
+ def need_config_change(self):
+ return self._dynamic_config._success_without_autounmask or \
+ self._dynamic_config._required_use_unsatisfied
def autounmask_breakage_detected(self):
try:
@@ -8665,7 +8668,7 @@ def _backtrack_depgraph(settings, trees, myopts,
myparams, myaction, myfiles, sp
backtrack_parameters=backtrack_parameters)
success, favorites = mydepgraph.select_files(myfiles)
- if success or mydepgraph.success_without_autounmask():
+ if success or mydepgraph.need_config_change():
break
elif not allow_backtracking:
break
@@ -8677,7 +8680,7 @@ def _backtrack_depgraph(settings, trees, myopts,
myparams, myaction, myfiles, sp
else:
break
- if not (success or mydepgraph.success_without_autounmask()) and
backtracked:
+ if not (success or mydepgraph.need_config_change()) and backtracked:
if debug:
writemsg_level(
diff --git a/pym/portage/tests/resolver/ResolverPlayground.py
b/pym/portage/tests/resolver/ResolverPlayground.py
index 646987d..8560871 100644
--- a/pym/portage/tests/resolver/ResolverPlayground.py
+++ b/pym/portage/tests/resolver/ResolverPlayground.py
@@ -674,7 +674,8 @@ class ResolverPlaygroundTestCase(object):
expected = x
break
elif key in (unstable_keywords,
needed_p_mask_changes,
- unsatisfied_deps) and expected is not None:
+ unsatisfied_deps, required_use_unsatisfied)
and \
+ expected is not None:
expected = set(expected)
elif key == forced_rebuilds and expected is not None:
@@ -693,10 +694,12 @@ class ResolverPlaygroundResult(object):
checks = (
success, mergelist, use_changes, license_changes,
unstable_keywords, slot_collision_solutions,
- circular_dependency_solutions, needed_p_mask_changes,
unsatisfied_deps, forced_rebuilds
+ circular_dependency_solutions, needed_p_mask_changes,
unsatisfied_deps, forced_rebuilds,
+ required_use_unsatisfied
)
optional_checks = (
forced_rebuilds,
+ required_use_unsatisfied,
unsatisfied_deps
)
@@ -714,6 +717,7 @@ class ResolverPlaygroundResult(object):
self.circular_dependency_solutions = None
self.unsatisfied_deps = frozenset()
self.forced_rebuilds = None
+ self.required_use_unsatisfied = None
if self.depgraph._dynamic_config._serialized_tasks_cache is not
None:
self.mergelist = []
@@ -780,6
[gentoo-portage-dev] Re: [PATCH] _backtrack_depgraph: fix bug #523048
On 09/18/2014 11:46 AM, Zac Medico wrote: This fixes _backtrack_depgraph to immediately report necessary REQUIRED_USE changes instead of discarding the graph. This is accomplished by replacing the depgraph.success_without_autounmask method with a new need_config_change method that accounts for both autounmask and REQUIRED_USE changes. X-Gentoo-Bug: 523048 X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=523048 --- I forgot to include the test case that goes along with this patch, but you can see it in this branch if you're interested: https://github.com/zmedico/portage/tree/bug_523048 -- Thanks, Zac
Re: [gentoo-portage-dev] [PATCH] _backtrack_depgraph: fix bug #523048
On Thu, 18 Sep 2014 11:46:55 -0700 Zac Medico zmed...@gentoo.org wrote: This fixes _backtrack_depgraph to immediately report necessary REQUIRED_USE changes instead of discarding the graph. This is accomplished by replacing the depgraph.success_without_autounmask method with a new need_config_change method that accounts for both autounmask and REQUIRED_USE changes. X-Gentoo-Bug: 523048 X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=523048 --- pym/_emerge/depgraph.py | 11 +++ pym/portage/tests/resolver/ResolverPlayground.py | 16 ++-- 2 files changed, 21 insertions(+), 6 deletions(-) LGTM -- Brian Dolbec dolsen
[gentoo-portage-dev] _solve_..slot_conflicts: fix bug #522084
From 963efa6fcf1e61d836d5292c88500a7c032cf46e Mon Sep 17 00:00:00 2001
From: Zac Medico zmed...@gentoo.org
Date: Thu, 18 Sep 2014 16:16:13 -0700
Subject: [PATCH] _solve_..slot_conflicts: fix bug #522084
Fix _solve_non_slot_operator_slot_conflicts to add all parents to the
conflict_graph, even for parents where the atom matches all relevant
nodes. Otherwise, we risk removing all of the matched nodes from the
graph, which would cause a missed update.
X-Gentoo-Bug: 522084
X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=522084
---
pym/_emerge/depgraph.py| 14 ++--
.../test_solve_non_slot_operator_slot_conflicts.py | 74 ++
2 files changed, 81 insertions(+), 7 deletions(-)
create mode 100644
pym/portage/tests/resolver/test_solve_non_slot_operator_slot_conflicts.py
diff --git a/pym/_emerge/depgraph.py b/pym/_emerge/depgraph.py
index 6332733..7bb5252 100644
--- a/pym/_emerge/depgraph.py
+++ b/pym/_emerge/depgraph.py
@@ -1171,12 +1171,15 @@ class depgraph(object):
for match in matched:
writemsg_level( match:
%s\n % match, level=logging.DEBUG, noiselevel=-1)
- if len(matched) == len(conflict):
- # All packages match.
- continue
+ if len(matched) 1:
+ # Even if all packages match, This
parent must still
+ # be added to the conflict_graph.
Otherwise, we risk
+ # removing all of these packages from
the depgraph,
+ # which could cause a missed update
(bug #522084).
+ conflict_graph.add(or_tuple(matched),
parent)
elif len(matched) == 1:
conflict_graph.add(matched[0], parent)
- elif len(matched) == 0:
+ else:
# This typically means that autounmask
broke a
# USE-dep, but it could also be due to
the slot
# not matching due to multislot (bug
#220341).
@@ -1188,9 +1191,6 @@ class depgraph(object):
for pkg in conflict:
writemsg_level(
non-match: %s\n % pkg,
level=logging.DEBUG, noiselevel=-1)
- else:
- # More than one packages matched, but
not all.
- conflict_graph.add(or_tuple(matched),
parent)
for pkg in indirect_conflict_pkgs:
for parent, atom in
self._dynamic_config._parent_atoms.get(pkg, []):
diff --git
a/pym/portage/tests/resolver/test_solve_non_slot_operator_slot_conflicts.py
b/pym/portage/tests/resolver/test_solve_non_slot_operator_slot_conflicts.py
new file mode 100644
index 000..ecda28e
--- /dev/null
+++ b/pym/portage/tests/resolver/test_solve_non_slot_operator_slot_conflicts.py
@@ -0,0 +1,74 @@
+# Copyright 2014 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License v2
+
+from portage.tests import TestCase
+from portage.tests.resolver.ResolverPlayground import (ResolverPlayground,
+ ResolverPlaygroundTestCase)
+
+class SolveNonSlotOperatorSlotConflictsTestCase(TestCase):
+
+ def testSolveNonSlotOperatorSlotConflicts(self):
+
+ ebuilds = {
+
+ app-misc/A-1 : {
+ EAPI: 5,
+ SLOT: 0/1,
+ PDEPEND: app-misc/B
+ },
+
+ app-misc/A-2 : {
+ EAPI: 5,
+ SLOT: 0/2,
+ PDEPEND: app-misc/B
+ },
+
+ app-misc/B-0 : {
+ EAPI: 5,
+ RDEPEND: app-misc/A:=
+ },
+
+ }
+
+ installed = {
+
+ app-misc/A-1 : {
+ EAPI: 5,
+ SLOT: 0/1,
+ PDEPEND: app-misc/B
+ },
+
+ app-misc/B-0 : {
+ EAPI: 5,
+ RDEPEND: app-misc/A:0/1=
+ },
+
+ }
+
+ world = [app-misc/A]
+
+ test_cases = (
+
+ # bug 522084
+ # In this case,
