Due to bug 590810 the invalid slot operator was removed instead of fixed. (In reply to Pacho Ramos from comment https://bugs.gentoo.org/show_bug.cgi?id=590810#c5) > the bug is invalid. Also, finally guile-2 went to the same slot as 1.8 > > Anyway, feel free to drop :*, the problem is that I don't know if this needs > to be rebuilt when guile subslot changes (I cannot downgrade again from > guile-2 to 1.8... if anyone can still update and check... it would be as > easy as update from guile-1.8 to 2 and see if gnutls[guile] needs to be > rebuilt by emerge @preserved-rebuild :/ Yes, it has to. When you build net-libs/gnutls[guile] we will get /var/tmp/portage/net-libs/gnutls-3.5.5/image/usr/lib64/guile/ └── 2.0 ├── guile-gnutls-v-2.so -> guile-gnutls-v-2.so.0.0.0 ├── guile-gnutls-v-2.so.0 -> guile-gnutls-v-2.so.0.0.0 ├── guile-gnutls-v-2.so.0.0.0 and this lib is linked against guile: # lddtree /var/tmp/portage/net-libs/gnutls-3.5.5/image/usr/lib64/guile/2.0/guile-gnutls-v-2.so.0.0.0 guile-gnutls-v-2.so.0.0.0 => /var/tmp/portage/net-libs/gnutls-3.5.5/image/usr/lib64/guile/2.0/guile-gnutls-v-2.so.0.0.0 (interpreter => none) libgnutls.so.30 => /usr/lib64/libgnutls.so.30 libz.so.1 => /lib64/libz.so.1 libidn.so.11 => /usr/lib64/libidn.so.11 libtasn1.so.6 => /usr/lib64/libtasn1.so.6 libnettle.so.6 => /usr/lib64/libnettle.so.6 libhogweed.so.4 => /usr/lib64/libhogweed.so.4 libgmp.so.10 => /usr/lib64/libgmp.so.10 libguile-2.0.so.22 => /usr/lib64/libguile-2.0.so.22 libgc.so.1 => /usr/lib64/libgc.so.1 libdl.so.2 => /lib64/libdl.so.2 libffi.so.6 => /usr/lib64/libffi.so.6 libunistring.so.2 => /usr/lib64/libunistring.so.2 libltdl.so.7 => /usr/lib64/libltdl.so.7 libcrypt.so.1 => /lib64/libcrypt.so.1 libm.so.6 => /lib64/libm.so.6 ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 libpthread.so.0 => /lib64/libpthread.so.0 libc.so.6 => /lib64/libc.so.6 So please add back an slot operator on dev-scheme/guile, i.e: diff --git a/net-libs/gnutls/gnutls-3.5.5.ebuild b/net-libs/gnutls/gnutls-3.5.5.ebuild index 5e892cd..d841a18 100644 --- a/net-libs/gnutls/gnutls-3.5.5.ebuild +++ b/net-libs/gnutls/gnutls-3.5.5.ebuild @@ -23,7 +23,7 @@ RDEPEND=">=dev-libs/libtasn1-4.3[${MULTILIB_USEDEP}] >=dev-libs/gmp-5.1.3-r1[${MULTILIB_USEDEP}] tools? ( sys-devel/autogen ) dane? ( >=net-dns/unbound-1.4.20[${MULTILIB_USEDEP}] ) - guile? ( >=dev-scheme/guile-1.8[networking] ) + guile? ( >=dev-scheme/guile-1.8:=[networking] ) nls? ( >=virtual/libintl-0-r1[${MULTILIB_USEDEP}] ) pkcs11? ( >=app-crypt/p11-kit-0.23.1[${MULTILIB_USEDEP}] ) zlib? ( >=sys-libs/zlib-1.2.8-r1[${MULTILIB_USEDEP}] )
I am not sure how this fixes the problem, it only delays it. There was a slot gor guile, there is now no slot. Had one written an ebuild that use guile now, he would not have specified any slot operator. GnuTLS (and others) should be written as if there was no slot.
The problem is simple: If you emerge net-libs/gnutls[guile] today, your package manager (emerge) will _not_ record that any action should be taken when depending dev-scheme/guile atom changes. So when a new dev-scheme/guile version which requires a rebuild becomes available, even that the guile maintainer has increased SUBSLOT of dev-scheme/guile to indicate an ABI breakage, your package manager would be unable to solve the problem for you. Emerge for example would tell you to run manually run `emerge @revdep-rebuild` due to FEATURES=preserve-libs. This will be solved when you tell your package manager to rebuild when a SLOT/sublot of a depending atom changes. I.e. with my proposed change you will tell your package manager: gnutls requires dev-scheme/guile but when SLOT _or_ SUBSLOT changes, gnutls must be rebuild. So next time dev-scheme/guile gets bumped (with a changed SLOT/SUBSLOT indication), emerge will automatically trigger the rebuild of net-libs/gnutls for the user (well, only after the user has already gnutls with the subslot operator on dev-scheme/guile recorded in his/her pkg db). Bug 590810 was about the fact that the subslot operator was invalid. I.e. an asterisk don't say "any" like many people imagine. On the contrary, it implicit tells portage to ignore any changed subslots...
I am probably missing something. Do you suggest that any library dependency should be written with := slot operator? Or is there something special with this case?
Any linked atom which provides a SUBSLOT should be written like that, yes. That's because if that linked atom has an API breakage we have to rebuild our atom and if we "subscribe" to that SUBSLOT the package manager will do that for the user without additional user interaction.
OK, so if like slot subslot is 0, then this applies to all packages, right? Why repoman does not provide a warning like it does provide if there is a slot?
I don't know. Probably because nobody requested such a feature yet. Feel free to file a bug against repoman ;) But that's out of scope of this request. Can we please get back a working slot operator on guile atom for gnutls?
(In reply to Thomas Deutschmann from comment #6) > I don't know. Probably because nobody requested such a feature yet. Feel > free to file a bug against repoman ;) > > But that's out of scope of this request. Can we please get back a working > slot operator on guile atom for gnutls? sure, I am just confused.
