Hi. When upgrading major versions I would like to suggest that the gnutls ebuild be modified to have similar behavior to the openssl ebuild: leave the old library binary in-place to prevent instantaneous system-wide breakage; present the user with a notice to do revdep-rebuild and then manually remove the binary. Rationale: just like openssl, gnutls is used among bootup services. Removing the binary can break some significant system services if USE="gnutls" was used to compile the system. The library is not like X, where if upgraded, most Internet/web services are unaffected. As an example, I have a PPC system that I just upgraded gnutls from 1.2.x to 1.4.x because the library was stabilized. Key items such as CUPS, Subversion, ghostscript, curl, PHP, Prelude, and others broke. Thanks for considering this.
Just a thought... I think it is somewhat different. The question is if revdep-rebuild can run or not. Since wget which is a key component in fetching files from the internet during emerge needs openssl, removing the libraries causes the system to be in invalid state without the ability to correct it. I don't know if gnutls has the same type of dependency, but if it only breaks subversion, cups or any other application, I think the current behavior is correct.
Hmm... I had thought that not removing the openssl library binary was out of intent to prevent breakage with some of the more sensitive dependencies. But if openssl's ebuild behavior is just intended to keep Portage operational, then I see that it may be unique in that respect. What would really be neat then would be a USE flag, or equivalent, for more uptime-critical libraries, such as db, gnutls, etc., that keeps the primary library binary in-place upon upgrade of a major version.
Besides, we had a bug w/ gnutls itself using its own old libraries to compile, better not risk other stuff doing the same.
*** Bug 148910 has been marked as a duplicate of this bug. ***
any reason why keeping this bug opened?
If someone wants to handle this issue, please reopen.
