-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
{{sorry if you receive this message twice. I've got smtp problems and I
had to switch smtp, so please reply to THIS message only}}
there are pieces of software that consist of multiple packages (either
by upstream decision, or by a Gentoo dev that splits a package) and
have the additional restriction that every component must have the
exact same version (or in some case the exact major version).
examples are Qt, and SynCE (I'll take the latter as example, as it is
my area of competence).
SynCE requires the same major version of other synce packages to work.
so, inside synce ebuilds I do this:
synce_PV=$(get_version_component_range 1-2)
DEPEND=" ... =app-pda/synce-libsynce-${synce_PV}* ... "
I introduced this in synce 0.13 series, without thinking to what would
be happened (today) when a user (me) would have tried to upgrade from
synce 0.13 to synce 0.14 (in my overlay now)
portage can't resolve the conflict by itself, because, as it tries to
touch one of dependencies (upgrading 0.13 => 0.14), the currently
installed synce meta ebuild 0.13 [which depends on =0.13* deps too]
won't allow that (that is: block everything that is not 0.13*)
as a consequence, the multiple-packages-per-slot error is shown when
upgrading packages [1].
after exchanging a few words with some devs on IRC, I understand no
solution actually exists for this. :-(
but still, that ebuild snippet is a formally legal directive (?)
what I want to state is that the user has to have installed all synce
of the same major version (0.13.*) to properly work
I can see also why portage is failing:
when (trying to) upgrading the first package, the whole package set
enters into a *transient* state, which is not valid for normal usage
(that is: one 0.14 lib, and all other 0.13 libs), but still has to be
valid in order for portage being able to upgrade correctly all the
packages, because when portage will end [successfully!], the system
will be again in a valid state.
what I am going to propose here is a resolution strategy for this
(although this whole thing simply tells me that portage misses some
knowledge about the problem, like for example that dependencies should
be enforced only at transaction boundaries, or simply that we have a
class of dependencies that is irrelevant while system is in transient
state)
but, without trying to introduce overcomplicated solutions, as an
user, I could solve the initial problem very easily:
resolution strategy for it is to unmerge the old synce-0.13 packages,
then the user will be able to install 0.14 packages.
so, if the user can do it, why can't portage handle it? (so that even
a not-so-smart user could painlessly get out of this mess)
many devs pointed out how Qt works, that is, only depends on
>=other-qt-library-${PV}, but that IMHO is an incomplete dep
specification (read: a workaround).
before I revert my changes to synce packages, are there any will to
change portage behavior in the near future to support and fix this?
[1]# emerge -auvDN world
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild U ] app-pda/synce-libsynce-0.14 [0.13] USE="hal" 364 kB [0=>1]
[ebuild U ] app-pda/synce-librapi2-0.14 [0.13.1] 483 kB [0=>1]
[ebuild U ] app-pda/synce-librra-0.14 [0.13] 414 kB [0=>1]
[ebuild U ] app-pda/synce-sync-engine-0.14 [0.13] 158 kB [0=>1]
[ebuild U ] app-pda/synce-hal-0.14 [0.13] 314 kB [0=>1]
[ebuild U ] app-pda/synce-kpm-0.14 [0.13] 90 kB [0=>1]
[ebuild U ] app-pda/synce-trayicon-0.14 [0.13] USE="-debug" 381 kB
[0=>1]
[ebuild U ] app-pda/synce-gvfs-0.3 [0.2.1] USE="-debug" 1,950 kB
[0=>1]
[ebuild U ] app-pda/synce-0.14 [0.13] USE="gnome hal -kde -serial"
0 kB [0=>1]
Total: 9 packages (9 upgrades), Size of downloads: 4,151 kB
Portage tree and overlays:
[0] /usr/portage
[1] /usr/local/portage/synce
!!! Multiple package instances within a single package slot have been
pulled
!!! into the dependency graph, resulting in a slot conflict:
app-pda/synce-librapi2:0
('ebuild', '/', 'app-pda/synce-librapi2-0.14', 'merge') pulled in by
=app-pda/synce-librapi2-0.14* required by ('ebuild', '/',
'app-pda/synce-librra-0.14', 'merge')
=app-pda/synce-librapi2-0.14* required by ('ebuild', '/',
'app-pda/synce-hal-0.14', 'merge')
=app-pda/synce-librapi2-0.14* required by ('ebuild', '/',
'app-pda/synce-gvfs-0.3', 'merge')
(and 1 more)
('installed', '/', 'app-pda/synce-librapi2-0.13.1', 'nomerge')
pulled in by
=app-pda/synce-librapi2-0.13* required by ('installed', '/',
'app-pda/synce-gnomevfs-0.13', 'nomerge')
app-pda/synce-libsynce:0
('ebuild', '/', 'app-pda/synce-libsynce-0.14', 'merge') pulled in by
=app-pda/synce-libsynce-0.14* required by ('ebuild', '/',
'app-pda/synce-gvfs-0.3', 'merge')
=app-pda/synce-libsynce-0.14* required by ('ebuild', '/',
'app-pda/synce-hal-0.14', 'merge')
=app-pda/synce-libsynce-0.14* required by ('ebuild', '/',
'app-pda/synce-librapi2-0.14', 'merge')
(and 3 more)
('installed', '/', 'app-pda/synce-libsynce-0.13', 'nomerge') pulled
in by
=app-pda/synce-libsynce-0.13* required by ('installed', '/',
'app-pda/synce-gnomevfs-0.13', 'nomerge')
=app-pda/synce-libsynce-0.13* required by ('installed', '/',
'app-pda/synce-librapi2-0.13.1', 'nomerge')
(and 1 more)
It may be possible to solve this problem by using package.mask to
prevent one of those packages from being selected. However, it is also
possible that conflicting dependencies exist such that they are
impossible to satisfy simultaneously. If such a conflict exists in the
dependencies of two different packages, then those packages can not be
installed simultaneously.
For more information, see MASKED PACKAGES section in the emerge man page
or refer to the Gentoo Handbook.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkp54CAACgkQV/B5axfzrPuMNQCghJ3aeEWRlTvKfJfK1JSSY8+R
lGwAnAgaO4n4mR+1E/mPTO2syf29xJDz
=ZhkE
-----END PGP SIGNATURE-----
