[opensuse-packaging] [library packaging policy] Example fixing of curl
For the library packaging policy as discussed previously this is an
example on how to fix an offending package. We take the example of
curl, as we have (ick) compat-curl2 and compat-curl3 packages alread,
which is a mess.
Curl currently is split into curl providing the /usr/bin/curl binrary
and the /usr/lib64/libcurl.so.X library and a curl-devel package with
development files.
The library packaging policy forces you to split off a libcurl4 package
with just the libcurl.so.4* shared libraries.
The library packaging policy forces you to rename curl-devel to
either libcurl-devel or libcurl4-devel if you want to support development
with different curl versions. We choose not to and rename it to
libcurl-devel which will depend on libcurl4 for this version.
For the renaming you need a proper Provides: curl-devel and Obsoletes:
curl-devel dependency for update to work. The split off of libcurl4
does not require anything special as shared lib requirements will take
care of what is necessary.
[Yes, I've started on the above, no need to do it for curl, but please
consider fixing your package early if you ever had the need to provide
compat-* packages and fix your package the next time you touch it
otherwise]
Thanks,
Richard.
--
Richard Guenther
Richard Guenther wrote:
For the library packaging policy as discussed previously this is an example on how to fix an offending package. We take the example of curl, as we have (ick) compat-curl2 and compat-curl3 packages alread, which is a mess.
:-( But yes, you're right, it's a bit messy.
Curl currently is split into curl providing the /usr/bin/curl binrary and the /usr/lib64/libcurl.so.X library and a curl-devel package with development files.
The library packaging policy forces you to split off a libcurl4 package with just the libcurl.so.4* shared libraries.
While you're at it, cosider splittig a curl-ca-bundle or curl-data or whatever, containing the file /usr/share/curl/curl-ca-bundle.crt, otherwise libcurl4 would have to depend on the main package anyway, which is what you're trying to avoid. thanks, Michal --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Mon, 2 Apr 2007, Michal Marek wrote:
Richard Guenther wrote:
For the library packaging policy as discussed previously this is an example on how to fix an offending package. We take the example of curl, as we have (ick) compat-curl2 and compat-curl3 packages alread, which is a mess.
:-( But yes, you're right, it's a bit messy.
Curl currently is split into curl providing the /usr/bin/curl binrary and the /usr/lib64/libcurl.so.X library and a curl-devel package with development files.
The library packaging policy forces you to split off a libcurl4 package with just the libcurl.so.4* shared libraries.
While you're at it, cosider splittig a curl-ca-bundle or curl-data or whatever, containing the file /usr/share/curl/curl-ca-bundle.crt, otherwise libcurl4 would have to depend on the main package anyway, which is what you're trying to avoid.
Does it not work at all without that file? Do old curl libraries work
with a new file? In the latter case depending on curl wouldn't be that
bad, or at least one curl-ca-bundle rpm would be enough for all old
versions.
Richard.
--
Richard Guenther
Richard Guenther wrote:
On Mon, 2 Apr 2007, Michal Marek wrote:
Richard Guenther wrote:
The library packaging policy forces you to split off a libcurl4 package with just the libcurl.so.4* shared libraries. While you're at it, cosider splittig a curl-ca-bundle or curl-data or whatever, containing the file /usr/share/curl/curl-ca-bundle.crt, otherwise libcurl4 would have to depend on the main package anyway, which is what you're trying to avoid.
Does it not work at all without that file?
libcurl won't be able to verify SSL certificates and will fail to download files from https: by default. The ZYPP people wouldn't be happy about that ;-)
Do old curl libraries work with a new file?
Yes, in fact the filename is just passed to openSSL, curl doesn't care about the content. And yes, the compat-curl* packages have been broken from the begining, because they don't depend on the package containing the curl-ca-bundle.crt file (they rely on the fact that a standard install will have curl.rpm installed).
In the latter case depending on curl wouldn't be that bad, or at least one curl-ca-bundle rpm would be enough for all old versions.
So what do you suggest, depending on the curl package, or splitting off a curl-ca-bundle package? Note that the first solution would create a circular dependency between curl and the latest libcurl*, which ZYPP doesn't like. Michael Matz wrote:
Richard is trying to fill a policy with life. Any other cleanups following from that should be done by the packager.
Well, if Richard told me "Hey Michal, fix your package!", I would simply do it myselves. I just wanted to point out that just splitting off the shared libs could break functionality in this case. Second, I don't know how to best apply the policy in such case. Michal --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Michal Marek wrote:
Richard Guenther wrote:
Do old curl libraries work with a new file?
Yes, in fact the filename is just passed to openSSL, curl doesn't care about the content. And yes, the compat-curl* packages have been broken from the begining, because they don't depend on the package containing the curl-ca-bundle.crt file (they rely on the fact that a standard install will have curl.rpm installed).
What about making all curl versions use /etc/ssl from openssl? cu Ludwig -- (o_ Ludwig Nussel //\ SUSE Labs V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Ludwig Nussel wrote:
Michal Marek wrote:
Do old curl libraries work with a new file? Yes, in fact the filename is just passed to openSSL, curl doesn't care about the content. And yes, the compat-curl* packages have been broken from the begining, because they don't depend on the package containing
Richard Guenther wrote: the curl-ca-bundle.crt file (they rely on the fact that a standard install will have curl.rpm installed).
What about making all curl versions use /etc/ssl from openssl?
on my todo :-) Michal --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Tue, 3 Apr 2007, Michal Marek wrote:
Richard Guenther wrote:
On Mon, 2 Apr 2007, Michal Marek wrote:
Richard Guenther wrote:
The library packaging policy forces you to split off a libcurl4 package with just the libcurl.so.4* shared libraries. While you're at it, cosider splittig a curl-ca-bundle or curl-data or whatever, containing the file /usr/share/curl/curl-ca-bundle.crt, otherwise libcurl4 would have to depend on the main package anyway, which is what you're trying to avoid.
Does it not work at all without that file?
libcurl won't be able to verify SSL certificates and will fail to download files from https: by default. The ZYPP people wouldn't be happy about that ;-)
Do old curl libraries work with a new file?
Yes, in fact the filename is just passed to openSSL, curl doesn't care about the content. And yes, the compat-curl* packages have been broken from the begining, because they don't depend on the package containing the curl-ca-bundle.crt file (they rely on the fact that a standard install will have curl.rpm installed).
In the latter case depending on curl wouldn't be that bad, or at least one curl-ca-bundle rpm would be enough for all old versions.
So what do you suggest, depending on the curl package, or splitting off a curl-ca-bundle package? Note that the first solution would create a circular dependency between curl and the latest libcurl*, which ZYPP doesn't like.
I have splitted off a curl-ca-bundle package and depend on that from libcurl4 now. For old compat libraries like libcurl3 I'll just depend on /usr/share/curl/curl-ca-bundle.crt instead.
Michael Matz wrote:
Richard is trying to fill a policy with life. Any other cleanups following from that should be done by the packager.
Well, if Richard told me "Hey Michal, fix your package!", I would simply do it myselves. I just wanted to point out that just splitting off the shared libs could break functionality in this case. Second, I don't know how to best apply the policy in such case.
Yes, I think it's good to tackle some problematic cases like this to
see if we can get it right.
Richard.
--
Richard Guenther
On 2007-04-03 11:48:25 +0200, Richard Guenther wrote:
I have splitted off a curl-ca-bundle package and depend on that from libcurl4 now. For old compat libraries like libcurl3 I'll just depend on /usr/share/curl/curl-ca-bundle.crt instead.
please use package dependencies when possible. they are less trouble some than file dependencies. -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Tue, 3 Apr 2007, Marcus Rueckert wrote:
On 2007-04-03 11:48:25 +0200, Richard Guenther wrote:
I have splitted off a curl-ca-bundle package and depend on that from libcurl4 now. For old compat libraries like libcurl3 I'll just depend on /usr/share/curl/curl-ca-bundle.crt instead.
please use package dependencies when possible. they are less trouble some than file dependencies.
For old compat package replacements I don't want to introduce the
curl-ca-bundle package but still want the sles9 libcurl2 package be
installable on sles10 where curl can fulfil the
/usr/share/curl/curl-ca-bundle.crt dependency. It's only to not
require a maintainance update there, otherwise I agree which is why
libcurl4 depends on the package, not the file.
Richard.
--
Richard Guenther
Hi, On Mon, 2 Apr 2007, Michal Marek wrote:
The library packaging policy forces you to split off a libcurl4 package with just the libcurl.so.4* shared libraries.
While you're at it, cosider splittig a curl-ca-bundle or curl-data or whatever, containing the file /usr/share/curl/curl-ca-bundle.crt, otherwise libcurl4 would have to depend on the main package anyway, which is what you're trying to avoid.
Richard is trying to fill a policy with life. Any other cleanups following from that should be done by the packager. Ciao, Michael. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Mon, 2 Apr 2007, Michael Matz wrote:
Hi,
On Mon, 2 Apr 2007, Michal Marek wrote:
The library packaging policy forces you to split off a libcurl4 package with just the libcurl.so.4* shared libraries.
While you're at it, cosider splittig a curl-ca-bundle or curl-data or whatever, containing the file /usr/share/curl/curl-ca-bundle.crt, otherwise libcurl4 would have to depend on the main package anyway, which is what you're trying to avoid.
Richard is trying to fill a policy with life. Any other cleanups following from that should be done by the packager.
No problem from my side - if I touch a package I can do it right from
the start ;)
Richard.
--
Richard Guenther
Richard Guenther
The library packaging policy forces you to rename curl-devel to either libcurl-devel or libcurl4-devel if you want to support development with different curl versions. We choose not to and rename it to libcurl-devel which will depend on libcurl4 for this version.
For the renaming you need a proper Provides: curl-devel and Obsoletes: curl-devel dependency for update to work. The split off of libcurl4 does not require anything special as shared lib requirements will take care of what is necessary.
Ok, some question on this, as I am currently working on the openssl split/rename: It is stated in http://en.opensuse.org/Package_Dependencies in the section "Renaming a package", that the old package name in the Provides tag should be versioned. The example given is: Name: package Version: 1.1 Requires: Provides: pac = 1.0 Obsoletes: pac <= 1.0 Conflicts: Now, this seems to imply that the version should be that one of the old version (before the rename was done). The argument given is that a later re-renaming should be possible. Looking at the libcurl-devel subpackage: %package -n libcurl-devel Provides: curl-devel = %{version}-%{release} Obsoletes: curl-devel This will expand to the current version-release number and seems to contradict the way it is done in the above document. What is the correct way to version the old package name in the Provides tag? Matthias --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Matthias Koenig wrote:
It is stated in http://en.opensuse.org/Package_Dependencies in the section "Renaming a package", that the old package name in the Provides tag should be versioned. The example given is:
Name: package Version: 1.1 Requires: Provides: pac = 1.0 Obsoletes: pac <= 1.0 Conflicts:
Now, this seems to imply that the version should be that one of the old version (before the rename was done). The argument given is that a later re-renaming should be possible.
Looking at the libcurl-devel subpackage: %package -n libcurl-devel Provides: curl-devel = %{version}-%{release} Obsoletes: curl-devel
This will expand to the current version-release number and seems to contradict the way it is done in the above document.
But if for whatever reason someone needs curl-devel = 7.16.1, should this dependency be satisfied by _any_ future version of libcurl-devel? Obsoleting just curl-devel <= 7.16.1 is a good idea. Michal --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Michal Marek wrote:
But if for whatever reason someone needs curl-devel = 7.16.1, should this dependency be satisfied by _any_ future version of libcurl-devel?
Obsoleting just curl-devel <= 7.16.1 is a good idea.
And also adding a simple comment, e. g. "curl-devel was last used in openSUSE 10.2" is useful. Without it, it will be hard to decide, when it is possible to wipe these lines out. Otherwise it will stay there forever. We still have Obsoletes valid for update from SuSE Linux 6! -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.cz Lihovarská 1060/12 tel: +420 284 028 966 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Michal Marek wrote:
Matthias Koenig wrote:
It is stated in http://en.opensuse.org/Package_Dependencies in the section "Renaming a package", that the old package name in the Provides tag should be versioned. The example given is:
Name: package Version: 1.1 Requires: Provides: pac = 1.0 Obsoletes: pac <= 1.0 Conflicts:
Now, this seems to imply that the version should be that one of the old version (before the rename was done). The argument given is that a later re-renaming should be possible.
Looking at the libcurl-devel subpackage: %package -n libcurl-devel Provides: curl-devel = %{version}-%{release} Obsoletes: curl-devel
This will expand to the current version-release number and seems to contradict the way it is done in the above document.
But if for whatever reason someone needs curl-devel = 7.16.1, should this dependency be satisfied by _any_ future version of libcurl-devel?
Any comments on this? What's "The Right Thing" here, Version: 1.1 Provides: pac = 1.0 Obsoletes: pac <= 1.0 OR Version: 1.1 Provides: pac = %version Obsoletes: pac <= 1.0 ? Lars, according to the wiki changelog you're the author of that section, can you comment? Thanks, Michal --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
participants (7)
-
Ludwig Nussel -
Marcus Rueckert -
Matthias Koenig -
Michael Matz -
Michal Marek -
Richard Guenther -
Stanislav Brabec