-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
libpst was just a collection of utilities to decode MS Outlook .pst files. It is in the process of being split into a shared library and the same utilities, so the shared library can be used by other clients, among them an Evolution plugin. The first attempt at this is at http://www.five-ten-sg.com/libpst/packages/libpst.spec and http://www.five-ten-sg.com/libpst/packages/libpst-0.6.35-1.src.rpm. That is not in the fedora cvs yet, because I think it unlikely that I have done a perfect job of that conversion. If anyone cares to look at that, let me know what needs to be changed.
Just a look at the spec:
On Wed, 08 Apr 2009 20:30:25 -0700, Carl wrote:
http://www.five-ten-sg.com/libpst/packages/libpst.spec and http://www.five-ten-sg.com/libpst/packages/libpst-0.6.35-1.src.rpm.
Requires: %{name}-libs = %{version}-%{release}
In the main utilities package, is this explicit dependency on the library package really needed? https://fedoraproject.org/wiki/Packaging/Guidelines#Requires
%description devel libpst-devel contains the library links and header fles you'll
s/fles/files/
%files libs %{_libdir}/libpst.so.*
%defattr is missing here.
%files devel %{_libdir}/libpst.so
%defattr is missing here.
%files
[...]
%docdir %{_datadir}/doc/%{name}-%{version} %{_datadir}/doc/%{name}-%{version}
%_datadir/doc is in default list of documentation directories. The %docdir line is redundant.
%dir %{_includedir}/%{name}-2 %{_includedir}/%{name}-2/*
Doesn't add any value and is the same as only
%{_includedir}/%{name}-2/
Michael Schwendt wrote, at 04/09/2009 05:34 PM +9:00:
Just a look at the spec:
On Wed, 08 Apr 2009 20:30:25 -0700, Carl wrote:
http://www.five-ten-sg.com/libpst/packages/libpst.spec and http://www.five-ten-sg.com/libpst/packages/libpst-0.6.35-1.src.rpm.
Requires: %{name}-libs = %{version}-%{release}
In the main utilities package, is this explicit dependency on the library package really needed? https://fedoraproject.org/wiki/Packaging/Guidelines#Requires
I have not checked this spec file in detail. however:
When I review packages I always request submitters to write exact EVR specific dependency between packages rebuilt from the same srpm and I think this is general for Fedora packages. ref: https://fedoraproject.org/wiki/Packaging/Guidelines#RequiringBasePackage
Regards, Mamoru
On Thu, 09 Apr 2009 18:06:57 +0900, Mamoru wrote:
Requires: %{name}-libs = %{version}-%{release}
In the main utilities package, is this explicit dependency on the library package really needed? https://fedoraproject.org/wiki/Packaging/Guidelines#Requires
I have not checked this spec file in detail. however:
When I review packages I always request submitters to write exact EVR specific dependency between packages rebuilt from the same srpm and I think this is general for Fedora packages. ref: https://fedoraproject.org/wiki/Packaging/Guidelines#RequiringBasePackage
Why?
Here "libpst" would Requires "libpst-libs" with an explicit version in addition to the automatic SONAME dep, but all other packages that would be linked to libpst would rely on the automatic SONAME dep.
More and more packagers even let -doc subpackages require the base package, so one cannot install -doc packages anymore without dependency bloat [as the base package often pulls in even further packages].
[...]
For library -devel packages there is a rationale. (Some distributors do the exact opposite and kill explicit versioned deps on base pkgs.)
We want the contents of -devel packages to be strictly in sync with the corresponding main library packages. Also with regard to %changelog. Emphasis is on "strictly", because there's an automatic SONAME dependency in a -devel pkg already. Builds done in mock don't need [and don't benefit from] the explicit dependency.
On installed systems, however, one can run into problems without an explicit dependency on the main library [base] package and when using plain rpmbuild or development tools. This is because adding -devel packages to the system would not enforce an update of the base packages. The already installed base packages would satisfy the dependency, but might contain bugs that cause the developer to tear his hairs till the base packages are updated, too. Don't expect developers to run a full "yum update" though, especially not if such an update would change the development environment heavily (and pull in lots of version upgrades, for example). So, when someone runs "yum install foo-devel" he shall get the matching release of "foo" even if an older ABI/API-compatible one is installed already. The older one may malfunction at run-time, whereas the matching one contains the needed bug-fixes. Hence the explicit Requires for -devel package users.
Michael Schwendt wrote, at 04/09/2009 06:52 PM +9:00:
On Thu, 09 Apr 2009 18:06:57 +0900, Mamoru wrote:
Requires: %{name}-libs = %{version}-%{release}
In the main utilities package, is this explicit dependency on the library package really needed? https://fedoraproject.org/wiki/Packaging/Guidelines#Requires
I have not checked this spec file in detail. however:
When I review packages I always request submitters to write exact EVR specific dependency between packages rebuilt from the same srpm and I think this is general for Fedora packages. ref: https://fedoraproject.org/wiki/Packaging/Guidelines#RequiringBasePackage
Why?
Here "libpst" would Requires "libpst-libs" with an explicit version in addition to the automatic SONAME dep, but all other packages that would be linked to libpst would rely on the automatic SONAME dep.
Because - As I already said almost all packages do so (e.g. rpm -q --requires perl) - And you explain the reason by yourself below (it is ensured that all packages are updated correctly, and distinguishing between developers v.s. non-developers does not make sense)
More and more packagers even let -doc subpackages require the base package, so one cannot install -doc packages anymore without dependency bloat [as the base package often pulls in even further packages].
Um, actually in many cases -doc packages must require the base package because of the directory ownership issue for which you often file bugs.
For library -devel packages there is a rationale. (Some distributors do the exact opposite and kill explicit versioned deps on base pkgs.)
We want the contents of -devel packages to be strictly in sync with the corresponding main library packages. Also with regard to %changelog. Emphasis is on "strictly", because there's an automatic SONAME dependency in a -devel pkg already. Builds done in mock don't need [and don't benefit from] the explicit dependency.
On installed systems, however, one can run into problems without an explicit dependency on the main library [base] package and when using plain rpmbuild or development tools. This is because adding -devel packages to the system would not enforce an update of the base packages. The already installed base packages would satisfy the dependency, but might contain bugs that cause the developer to tear his hairs till the base packages are updated, too. Don't expect developers to run a full "yum update" though, especially not if such an update would change the development environment heavily (and pull in lots of version upgrades, for example). So, when someone runs "yum install foo-devel" he shall get the matching release of "foo" even if an older ABI/API-compatible one is installed already. The older one may malfunction at run-time, whereas the matching one contains the needed bug-fixes. Hence the explicit Requires for -devel package users.
On Thu, 09 Apr 2009 19:24:31 +0900, Mamoru wrote:
Michael Schwendt wrote, at 04/09/2009 06:52 PM +9:00:
On Thu, 09 Apr 2009 18:06:57 +0900, Mamoru wrote:
Requires: %{name}-libs = %{version}-%{release}
In the main utilities package, is this explicit dependency on the library package really needed? https://fedoraproject.org/wiki/Packaging/Guidelines#Requires
I have not checked this spec file in detail. however:
When I review packages I always request submitters to write exact EVR specific dependency between packages rebuilt from the same srpm and I think this is general for Fedora packages. ref: https://fedoraproject.org/wiki/Packaging/Guidelines#RequiringBasePackage
Why?
Here "libpst" would Requires "libpst-libs" with an explicit version in addition to the automatic SONAME dep, but all other packages that would be linked to libpst would rely on the automatic SONAME dep.
Because
- As I already said almost all packages do so (e.g. rpm -q --requires perl)
- And you explain the reason by yourself below (it is ensured that all packages are updated correctly, and distinguishing between developers v.s. non-developers does not make sense)
I can only explain the reason for the original guidelines, not the reason why the additional "should" for non-devel subpackages was added.
More and more packagers even let -doc subpackages require the base package, so one cannot install -doc packages anymore without dependency bloat [as the base package often pulls in even further packages].
Um, actually in many cases -doc packages must require the base package because of the directory ownership issue for which you often file bugs.
That can be fixed in the subpackages with %dir, for example.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Thanks to everyone for their comments. Thinking about this dependency from the main libpst package to the -libs subpackage, it seems that we should have
Requires: %{name}-libs >= %{version}-%{release}
in the main package. Currently, the soname is libpst.so.2 with libtool - -version-info 2:0:0 and library name libpst.so.2.0.0. If we add some interfaces, but don't change any existing interfaces, then - -version-info goes to 3:0:1 and the soname stays at libpst.so.2 and the library name is libpst.so.2.1.0. We need some mechanism to capture that dependency. Yes, this version of the executables needs libpst.so.2, but it won't run with the original libpst.so.2.0.0. How is this sort of dependency handled in other packages? I think the above Requires solves that within this package.
It would also be nice to allow installing multiple (matching) -devel and -libs packages for different major versions.
http://www106.pair.com/rhp/parallel.html
Is there anything (else) that needs to be done to enable parallel installs for this package? The -devel include files already go into /usr/include/libpst-2 where the 2 comes from the SONAME.
If we change interfaces, with -version-info up to 4:0:0, soname is libpst.so.4, library name is libpst.so.4.0.0, and the headers go into /usr/include/libpst-4. Is there anything here that would prevent parallel installs for the so.2 and so.4 versions?
Carl Byington carl@five-ten-sg.com writes:
Thanks to everyone for their comments. Thinking about this dependency from the main libpst package to the -libs subpackage, it seems that we should have
Requires: %{name}-libs >= %{version}-%{release}
in the main package.
I think the standard recommendation is to use a requires like this with "=", not ">=", to bind together different subpackages. It's almost never a good idea to let non-matching subpackages be installed together ... unless you would like to take on the burden of testing all such combinations to see if they work.
There is a packaging guideline about this IIRC. Have you read https://fedoraproject.org/wiki/Packaging:Guidelines
regards, tom lane
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I think the standard recommendation is to use a requires like this with "=", not ">=", to bind together different subpackages. It's almost never a good idea to let non-matching subpackages be installed together ... unless you would like to take on the burden of testing all such combinations to see if they work.
But if the main executables require an exact version match to the -libs package, then we cannot do parallel install of multiple (matching) - -devel,-libs packages, while leaving the executables installed and using the older version of the -libs package.
None of this matters if fedora packaging in general does not support parallel installs. If that is the case, then yes, we can use '=' in that Requires.
Carl Byington wrote:
But if the main executables require an exact version match to the -libs package, then we cannot do parallel install of multiple (matching)
- -devel,-libs packages, while leaving the executables installed and
using the older version of the -libs package.
None of this matters if fedora packaging in general does not support parallel installs. If that is the case, then yes, we can use '=' in that Requires.
We do not support parallel installs. In cases where multiple versions of a library are needed, a compatibility package has to be built for the old one. But in general we just rebuild all dependent packages against the new version.
Kevin Kofler
On Thu, 09 Apr 2009 10:08:33 -0700, Carl wrote:
Thanks to everyone for their comments. Thinking about this dependency from the main libpst package to the -libs subpackage, it seems that we should have
Requires: %{name}-libs >= %{version}-%{release}
in the main package.
That would not be more accurate, because you could not guarantee that _any_ libpst-libs package with a higher %version would be compatible. Especially not if %version has nothing to do with the libtool library version.
Since the tools/apps in libpst main pkg are linked with the library from within the same src.rpm, you rather want to depend on the exact %version-%release of the -libs package.
Actually, this is likely the reason for the subpackage Requires guidelines. ;) Non-library packages are not affected.
External packages linked with libpst are not affected either and can rely on the automatic SONAME dependency.
Currently, the soname is libpst.so.2 with libtool
- -version-info 2:0:0 and library name libpst.so.2.0.0. If we add some
interfaces, but don't change any existing interfaces, then
- -version-info goes to 3:0:1 and the soname stays at libpst.so.2 and
the library name is libpst.so.2.1.0. We need some mechanism to capture that dependency. Yes, this version of the executables needs libpst.so.2, but it won't run with the original libpst.so.2.0.0. How is this sort of dependency handled in other packages? I think the above Requires solves that within this package.
The latest published package release of libpst implements the needed library interfaces for anything that depends on libpst.so.2. Older release of libpst are not available anymore.
It would also be nice to allow installing multiple (matching) -devel and -libs packages for different major versions.
That would only be possible with changed package %name, relocated install locations. Or else the packages would conflict or upgrade eachother.
If we change interfaces, with -version-info up to 4:0:0, soname is libpst.so.4, library name is libpst.so.4.0.0, and the headers go into /usr/include/libpst-4. Is there anything here that would prevent parallel installs for the so.2 and so.4 versions?
Yes, the libpst.so symlink from the -devel pkgs.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
That would not be more accurate, because you could not guarantee that _any_ libpst-libs package with a higher %version would be compatible. Especially not if %version has nothing to do with the libtool library version.
The combination of 'Requires: %{name}-libs >= %{version}-%{release}' with the automatic soname dependency would only be satisfied by a version of the -libs package that 1) implements libpst.so.2, and 2) is at least as recent as the current version. Anything satisfying both of those conditions must implement all of the interfaces needed by the current executables. Or am I missing something?
External packages linked with libpst are not affected either and can rely on the automatic SONAME dependency.
How does that work in the case of
a) early version with -version-info 2:0:0, soname .2, library .2.0.0 b) newer version with -version info 3:0:1, soname .2, library .2.1.0 c) other package built against the newer version with automatic dependency on soname .2
User installs the early version from (a) which provides soname .2, and other package (c) which depends on soname .2 - but really needs library 2.1.0.
If the other package just 'Requires: libpst-libs' without any version, it would seem to be satisfied by the early version from (a). It seems that the other package would need to add some >=release.version to that requires. If so, then the main libpst package should also use that same Requires.
In any case, I think that the main libpst package should Require the - -libs subpackage using the same (version or not) line as in any other package that depends on libpst-libs.
Or is it the case that these sorts of dependencies are handled by the repository and fedora build system? In the sense, that if we upgrade to - -version-info 3:0:1 and rebuild libpst, and the other package is built against that new version, then a user with an existing old version from (a) doing 'yum install other-pkg' will automatically get the newer libpst, even though the soname dependency would seem to be satisfied by the existing libpst.so.2 on that end user system. I don't see any mechanism in place to do that, but it would be nice.
The other alternative is that *any* change to the interface, even just adding a new interface, results in an soname bump.
Yes, the libpst.so symlink from the -devel pkgs.
Ok, I will ignore the parallel install issues for now (unless you have a suggestion for a fix).
On Thu, 09 Apr 2009 13:05:14 -0700, Carl wrote:
The combination of 'Requires: %{name}-libs >= %{version}-%{release}' with the automatic soname dependency would only be satisfied by a version of the -libs package that 1) implements libpst.so.2, and 2) is at least as recent as the current version. Anything satisfying both of those conditions must implement all of the interfaces needed by the current executables. Or am I missing something?
You're trying to optimise the dependency for cherry-picking of package builds. With an ordinary library package and strict libtool versioning it would be possible to do it that way, but pkg %{name} and pkg %{name}-libs are built from the same src.rpm anyway, are published together, and depsolvers typically look at only the latest release of a pkg.
With your less strict dependency, one could "yum update %name-libs" to a higher %version while keeping an older installed %name pkg. As I said, the '>=' dependency is less accurate than '='. The old %name pkg might suffer from bugs -- vulnerabilities even, with the %name-libs %changelog mentioning a fix but the %name pkg being too old.
There is no logical AND involved in depsolving a set of dependencies, as far as I know. You've got two dependencies,
1.) %{name}-libs >= %{version}-%{release} 2.) libpst.so.2
which theoretically could be satisfied by two separate sets of packages. It can happen that the depsolver first resolves dep 1, which could be satisfied by a pkg libpst-libs that provides libpst.so.3 (!), and then the depsolver finds libpst.so.2 in a different package, e.g. libpst2-libs, a package that can be installed in parallel. If the pkg that satisfies dep 1 provides the stuff needed by dep 2, there is not much benefit, because it's the latest release of %name-libs in the repo that satisfies the 'greater or equal' anyway (and hides all older %name-libs pkgs as it is supposed to update/upgrade them).
External packages linked with libpst are not affected either and can rely on the automatic SONAME dependency.
How does that work in the case of
a) early version with -version-info 2:0:0, soname .2, library .2.0.0 b) newer version with -version info 3:0:1, soname .2, library .2.1.0 c) other package built against the newer version with automatic dependency on soname .2
User installs the early version from (a) which provides soname .2, and other package (c) which depends on soname .2 - but really needs library 2.1.0.
If the other package just 'Requires: libpst-libs' without any version, it would seem to be satisfied by the early version from (a).
A non-versioned explicit Requires on a package name is not better than the automatic dep on the SONAME. It's worse -- if you keep package renaming and library moving in mind.
It seems that the other package would need to add some >=release.version to that requires. If so, then the main libpst package should also use that same Requires.
In any case, I think that the main libpst package should Require the
- -libs subpackage using the same (version or not) line as in any other
package that depends on libpst-libs.
The only explicit Requires that's plausible for subpackage inter-package dependencies is '... = %version-%release" to require exactly the subpackages built from the same src.rpm. This strict dependency makes sense for all a src.rpm's subpackages with inter-package dependencies on eachother actually. Documentation subpackages don't need such a dep at all, if they can be displayed with a reader from an external package.
Rule of thumb as I see it: If there is an inter-package dependency between sub-packages built from the same src.rpm (e.g. library interfaces, command-line/tool interfaces, data files, files needed at run-time), make the dependency explicit and a strict "... = %version-%release".
Or is it the case that these sorts of dependencies are handled by the repository and fedora build system? In the sense, that if we upgrade to
- -version-info 3:0:1 and rebuild libpst, and the other package is built
against that new version, then a user with an existing old version from (a) doing 'yum install other-pkg' will automatically get the newer libpst,
No automatic rebuilds of apps are done if a build dependency is upgraded.
If "other-pkg" really needs a minimum version of a library package at run-time, that must be added as an explicit Requires, unfortunately. With a spec file comment explaining the necessity. Explicit minimum versions for BuildRequires and Requires increase the package maintenance overhead (and require developers and packagers to keep their "configure" checks and minimum versions very accurate and in sync). Package maintainers must be careful with library version upgrades -- and hope that users apply all Updates regularly. ;-)
Carl Byington wrote:
How does that work in the case of
a) early version with -version-info 2:0:0, soname .2, library .2.0.0 b) newer version with -version info 3:0:1, soname .2, library .2.1.0 c) other package built against the newer version with automatic dependency on soname .2
User installs the early version from (a) which provides soname .2, and other package (c) which depends on soname .2 - but really needs library 2.1.0.
If the other package just 'Requires: libpst-libs' without any version, it would seem to be satisfied by the early version from (a). It seems that the other package would need to add some >=release.version to that requires. If so, then the main libpst package should also use that same Requires.
It doesn't. :-)
That's one of the limitations with the soname dependencies. Some packages have explicit versioned dependencies when such a relation is known, but in most cases it isn't and so there's no such dependency, the user is just expected to upgrade everything (which will replace a with b), not just the package c.
The only way you can get RPM to autodetect dependencies without soname bumps is with symbol versioning. If you can get upstream to use symbol versioning on the platforms which support it (e.g. Fedora (on all architectures)) to mark each symbol with the version it was first introduced in (or if you ARE upstream and can do that change there), then RPM will add automatic dependencies based on those and solve this problem. Note that for this to work, there is NO NEED to actually have more than one version for any given symbol! So this can be done without introducing any non-portability, the symbol versioning would just be used on the platforms where it is supported. (In other words: such a use of symbol versioning would really be symbol version-marking, not versioning.) But upstream needs to support it, most don't, unfortunately. (One warning though: versions should only be added to NEW symbols. Adding symbol versions to existing symbols is an ABI change and thus needs a soname bump.)
Examples: 1. unversioned symbol: foo * contains no version information whatsoever * RPM has no way to know when foo was first introduced 2. versioned symbol: foo@LIBBAR_2_1_0, foo@LIBBAR_2_2_0 * symbol versioning as used by glibc * multiple versions of the symbol * old programs use the old version of the symbol, newly-rebuilt ones use the new version * usually a bad idea, as rebuilds magically change the program's behavior * not portable, because not all platforms support symbol versioning * different functions should have different names! 3. version-marked symbol: foo@LIBBAR_2_1_0 (and no other foo@* symbol) * conservative use of symbol versioning * contains version information which RPM can use for automatic deps * programs using foo will have a libbar.so.2(LIBBAR_2_1_0) autodep * on OSes without symbol versioning, just foo (as in 1.) will be used * as in 1., the function foo must remain binary compatible The solution 3. is what I'm suggesting to use. RPM autodeps would be much safer if all upstream projects used that.
Kevin Kofler
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
- version-marked symbol: foo@LIBBAR_2_1_0 (and no other foo@*
symbol)
- conservative use of symbol versioning
- contains version information which RPM can use for automatic deps
- programs using foo will have a libbar.so.2(LIBBAR_2_1_0) autodep
- on OSes without symbol versioning, just foo (as in 1.) will be
used
- as in 1., the function foo must remain binary compatible
The solution 3. is what I'm suggesting to use. RPM autodeps would be much safer if all upstream projects used that.
I am both the upstream and the packager for this project, and I am willing to make changes (well, within reason) to make it fit nicely into Fedora. Do you have an example of a fedora package that uses this approach so I can study it, or is there a reference with a bit more detail of exactly how to create these versioned symbols and the rules to be followed when deciding which symbols need to be versioned?
On Thu, 2009-04-09 at 21:19 -0700, Carl Byington wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
- version-marked symbol: foo@LIBBAR_2_1_0 (and no other foo@*
symbol)
- conservative use of symbol versioning
- contains version information which RPM can use for automatic deps
- programs using foo will have a libbar.so.2(LIBBAR_2_1_0) autodep
- on OSes without symbol versioning, just foo (as in 1.) will be
used
- as in 1., the function foo must remain binary compatible
The solution 3. is what I'm suggesting to use. RPM autodeps would be much safer if all upstream projects used that.
I am both the upstream and the packager for this project, and I am willing to make changes (well, within reason) to make it fit nicely into Fedora. Do you have an example of a fedora package that uses this approach so I can study it, or is there a reference with a bit more detail of exactly how to create these versioned symbols and the rules to be followed when deciding which symbols need to be versioned?
You can use "yum provides 'lib*(*_*)'" to find a few different packages, one simplish one I know of is "ustr" (doesn't use autotools).