Hello, Next week I plan to update nettle to 3.1.1 and gnutls to 3.4.0 in rawhide. That would require a recompilation of the packages that depend on them. Any objections?
regards, Nikos
On 04/27/2015 03:56 PM, Nikos Mavrogiannopoulos wrote:
Hello, Next week I plan to update nettle to 3.1.1 and gnutls to 3.4.0 in rawhide. That would require a recompilation of the packages that depend on them. Any objections?
My concern is that there's probably a lot of 3rd party apps that use gnutls. Even if it's just as simple as rebuilding, it probably takes a while for them to switch over.
I think it would make sense to keep ABI compatibility with the old soname for one Fedora release, just to give 3rd parties time to transition over. I could help making an ABI compat package for this if you agree it makes sense?
This would also make it easier to get the soname bump into rawhide.
On 27 April 2015 at 15:33, Kalev Lember kalevlember@gmail.com wrote:
I think it would make sense to keep ABI compatibility with the old soname for one Fedora release, just to give 3rd parties time to transition over. I could help making an ABI compat package for this if you agree it makes sense?
From my point of view, this is a great idea. Without a compat package
we can expect weeks of pain.
Richard
On 04/27/2015 04:39 PM, Richard Hughes wrote:
On 27 April 2015 at 15:33, Kalev Lember kalevlember@gmail.com wrote:
I think it would make sense to keep ABI compatibility with the old soname for one Fedora release, just to give 3rd parties time to transition over. I could help making an ABI compat package for this if you agree it makes sense?
From my point of view, this is a great idea. Without a compat package we can expect weeks of pain.
Nettle doesn't use symbol versions, so having two versions of that library in the same process could have interesting effects.
On Mon, 2015-04-27 at 16:33 +0200, Kalev Lember wrote:
On 04/27/2015 03:56 PM, Nikos Mavrogiannopoulos wrote:
Hello, Next week I plan to update nettle to 3.1.1 and gnutls to 3.4.0 in rawhide. That would require a recompilation of the packages that depend on them. Any objections?
My concern is that there's probably a lot of 3rd party apps that use gnutls. Even if it's just as simple as rebuilding, it probably takes a while for them to switch over. I think it would make sense to keep ABI compatibility with the old soname for one Fedora release, just to give 3rd parties time to transition over. I could help making an ABI compat package for this if you agree it makes sense?
A compat library is a non-trivial task. In that particular ABI change there were changes in header definitions (e.g., rearrangement of enumerations), and functions which were either not safe to use under TLS 1.2, or related to RSA-EXPORT ciphersuites were removed [0]. It may be easier to ship both gnutls libraries as debian does because there are versioned symbols, but I'm not sure whether that's acceptable. I've not seen it in other packages in fedora.
(as Florian mentioned, the above can only be done for gnutls, the nettle library introduced versioned symbols only in its latest release).
regards, Nikos
[0]. http://www.gnutls.org/manual/html_node/Upgrading-from-previous-versions.html...
On 04/28/2015 09:10 AM, Nikos Mavrogiannopoulos wrote:
On Mon, 2015-04-27 at 16:33 +0200, Kalev Lember wrote:
My concern is that there's probably a lot of 3rd party apps that use gnutls. Even if it's just as simple as rebuilding, it probably takes a while for them to switch over. I think it would make sense to keep ABI compatibility with the old soname for one Fedora release, just to give 3rd parties time to transition over. I could help making an ABI compat package for this if you agree it makes sense?
A compat library is a non-trivial task. In that particular ABI change there were changes in header definitions (e.g., rearrangement of enumerations), and functions which were either not safe to use under TLS 1.2, or related to RSA-EXPORT ciphersuites were removed [0]. It may be easier to ship both gnutls libraries as debian does because there are versioned symbols, but I'm not sure whether that's acceptable. I've not seen it in other packages in fedora.
We have a bunch, for example see gtk2/gtk3 as an example how to do full parallel installation and support parallel APIs over a long period of time.
In this case, however, I think it makes sense to not do a full parallel installation, but just enough to preserve the ABI compatibility and exclude headers and anything else that could be used to link against it. This makes sure that anything newly compiled is built with the new gnutls and we don't lock ourselves into supporting gnutls28 forever.
(as Florian mentioned, the above can only be done for gnutls, the nettle library introduced versioned symbols only in its latest release).
Sure, I was only concerned about gnutls anyway. Nettle is more like a gnutls implementation details, not so many other programs that are using it.
On 04/28/2015 12:04 PM, Kalev Lember wrote:
In this case, however, I think it makes sense to not do a full parallel installation, but just enough to preserve the ABI compatibility and exclude headers and anything else that could be used to link against it. This makes sure that anything newly compiled is built with the new gnutls and we don't lock ourselves into supporting gnutls28 forever.
I gave a stab at compat-gnutls28: https://bugzilla.redhat.com/show_bug.cgi?id=1215997
Nikos, can you review the new package, so that it can be built together with the gnutls 3.4 update in rawhide?
On Tue, Apr 28, 2015 at 11:04 AM, Kalev Lember kalevlember@gmail.com wrote:
On 04/28/2015 09:10 AM, Nikos Mavrogiannopoulos wrote:
On Mon, 2015-04-27 at 16:33 +0200, Kalev Lember wrote:
My concern is that there's probably a lot of 3rd party apps that use gnutls. Even if it's just as simple as rebuilding, it probably takes a while for them to switch over. I think it would make sense to keep ABI compatibility with the old soname for one Fedora release, just to give 3rd parties time to transition over. I could help making an ABI compat package for this if you agree it makes sense?
A compat library is a non-trivial task. In that particular ABI change there were changes in header definitions (e.g., rearrangement of enumerations), and functions which were either not safe to use under TLS 1.2, or related to RSA-EXPORT ciphersuites were removed [0]. It may be easier to ship both gnutls libraries as debian does because there are versioned symbols, but I'm not sure whether that's acceptable. I've not seen it in other packages in fedora.
We have a bunch, for example see gtk2/gtk3 as an example how to do full parallel installation and support parallel APIs over a long period of time.
In this case, however, I think it makes sense to not do a full parallel installation, but just enough to preserve the ABI compatibility and exclude headers and anything else that could be used to link against it. This makes sure that anything newly compiled is built with the new gnutls and we don't lock ourselves into supporting gnutls28 forever.
libpng15 is a good example of how to achieve the above.
Peter
-
Florian Weimer -
Kalev Lember -
Nikos Mavrogiannopoulos -
Peter Robinson -
Richard Hughes