Is there, or should there be, any Fedora packaging policy about the following question? (I see nothing in the Guidelines at the moment.)
Given a single SRPM generating multiple sub-RPMs, some of which depend on each other, how hard should the maintainer try to ensure that matching versions of the sub-RPMs are installed? Possible answers include:
1. Do nothing, rely on automatically generated requires (eg, the major version of a shared library's soname). Maximum flexibility, maximum possibility of allowing installations that don't actually work.
2. Put in cross-package requires of the form Requires: %{name}-libs = %{version} ie, constrain to "same upstream version"
3. Put in cross-package requires of the form Requires: %{name}-libs = %{version}-%{release} ie, constrain to "exact same build"
Currently, I have some packages that do #2 and some that do #3, and I have an open bug suggesting that #3 is the way to go because it ensures yum will update all installed subpackages together: https://bugzilla.redhat.com/show_bug.cgi?id=444271
However this idea was questioned on an upstream mailing list on the grounds that users shouldn't be forced to update all subpackages together.
I've got mixed feelings about it myself. I see the point about not constraining users unnecessarily, but there is no way that anyone is ever going to have done any testing on mix-and-match installations --- certainly I haven't got time to. (As an example of possible problems, different %{release} builds might have used different configure options, leading to builds that really are incompatible.) I think I'd rather ship RPMs that try to enforce that only tested combinations are installed. There's always --nodeps for those who think they're smarter than me...
So, first, has anyone got an opinion about this, and second, should a policy recommendation be enshrined?
regards, tom lane
Tom Lane wrote:
Is there, or should there be, any Fedora packaging policy about the following question? (I see nothing in the Guidelines at the moment.)
Given a single SRPM generating multiple sub-RPMs, some of which depend on each other, how hard should the maintainer try to ensure that matching versions of the sub-RPMs are installed? Possible answers include:
- Do nothing, rely on automatically generated requires (eg, the major
version of a shared library's soname). Maximum flexibility, maximum possibility of allowing installations that don't actually work.
- Put in cross-package requires of the form Requires: %{name}-libs = %{version}
ie, constrain to "same upstream version"
- Put in cross-package requires of the form Requires: %{name}-libs = %{version}-%{release}
ie, constrain to "exact same build"
3. definitely is the way to go, we currently already mandate this for -devel subpackages, which we need to generalize I think, we should mandate that:
a. -devel subpackages require the main or a -libs subpackage b. that any inter srpm deps (including those from -devel on main / -libs) should be fully versioned
Regards,
Hans
Hans de Goede wrote:
Tom Lane wrote:
Is there, or should there be, any Fedora packaging policy about the following question? (I see nothing in the Guidelines at the moment.)
Given a single SRPM generating multiple sub-RPMs, some of which depend on each other, how hard should the maintainer try to ensure that matching versions of the sub-RPMs are installed? Possible answers include:
- Do nothing, rely on automatically generated requires (eg, the major
version of a shared library's soname). Maximum flexibility, maximum possibility of allowing installations that don't actually work.
- Put in cross-package requires of the form Requires: %{name}-libs = %{version}
ie, constrain to "same upstream version"
- Put in cross-package requires of the form Requires: %{name}-libs = %{version}-%{release}
ie, constrain to "exact same build"
- definitely is the way to go, we currently already mandate this for
-devel subpackages, which we need to generalize I think, we should mandate that:
a. -devel subpackages require the main or a -libs subpackage b. that any inter srpm deps (including those from -devel on main / -libs) should be fully versioned
s/inter/intra/
I think this is the way to go.
-Toshio
2008/5/5 Hans de Goede j.w.r.degoede@hhs.nl:
Tom Lane wrote:
[snip]
- Put in cross-package requires of the form Requires: %{name}-libs = %{version}-%{release}
ie, constrain to "exact same build"
- definitely is the way to go, we currently already mandate this for
-devel subpackages, which we need to generalize I think, we should mandate that:
a. -devel subpackages require the main or a -libs subpackage b. that any inter srpm deps (including those from -devel on main / -libs) should be fully versioned
Assuming that 3. is indeed the way to go (and that seems right to me), shouldn't rpmbuild actually be fixed to enforce this?
On Thu, 2008-05-08 at 00:30 +0100, Jonathan Underwood wrote:
Assuming that 3. is indeed the way to go (and that seems right to me), shouldn't rpmbuild actually be fixed to enforce this?
No, because 3 isn't always true, and rpm has no way of knowing what a -libs package means.
~spot
"Tom "spot" Callaway" tcallawa@redhat.com writes:
On Thu, 2008-05-08 at 00:30 +0100, Jonathan Underwood wrote:
Assuming that 3. is indeed the way to go (and that seems right to me), shouldn't rpmbuild actually be fixed to enforce this?
No, because 3 isn't always true, and rpm has no way of knowing what a -libs package means.
I agree. This is very probably good as a standard policy recommendation, but it's a long way from there to a "no exceptions" policy.
The bottom line as far as I can tell is that enforcing same-release match for subpackages of an RPM is a good idea when you don't want to think very hard about the compatibility implications of a mixed-release situation. If a package maintainer *is* willing to think hard, we should allow him to do that.
regards, tom lane
Le Lun 5 mai 2008 18:40, Tom Lane a écrit :
Given a single SRPM generating multiple sub-RPMs, some of which depend on each other, how hard should the maintainer try to ensure that matching versions of the sub-RPMs are installed?
If you fear that mismatched subpackages may not work well together, I'd have them all conflict with versions < exact same build. What you're trying to describe is a conflict. Any sane repository will always have subpackages at the same build level, and not self-conflict (that's the main reason we ask people to avoid conflicts today; it wouldn't apply in your case).
Nicolas Mailhot wrote:
Le Lun 5 mai 2008 18:40, Tom Lane a écrit :
Given a single SRPM generating multiple sub-RPMs, some of which depend on each other, how hard should the maintainer try to ensure that matching versions of the sub-RPMs are installed?
If you fear that mismatched subpackages may not work well together, I'd have them all conflict with versions < exact same build. What you're trying to describe is a conflict. Any sane repository will always have subpackages at the same build level, and not self-conflict (that's the main reason we ask people to avoid conflicts today; it wouldn't apply in your case).
Ugh, no no no, thats just ugly for no good reason, just add a Requires to the full version of the base package, or the sub-package that the sub-package needs.
Regards,
Hans
Le Lun 5 mai 2008 21:35, Hans de Goede a écrit :
Nicolas Mailhot wrote:
Le Lun 5 mai 2008 18:40, Tom Lane a écrit :
Given a single SRPM generating multiple sub-RPMs, some of which depend on each other, how hard should the maintainer try to ensure that matching versions of the sub-RPMs are installed?
If you fear that mismatched subpackages may not work well together, I'd have them all conflict with versions < exact same build. What you're trying to describe is a conflict. Any sane repository will always have subpackages at the same build level, and not self-conflict (that's the main reason we ask people to avoid conflicts today; it wouldn't apply in your case).
Ugh, no no no, thats just ugly for no good reason, just add a Requires to the full version of the base package, or the sub-package that the sub-package needs.
That only works if you have a nice subpackage hierarchy. Not all packages are like that
"Nicolas Mailhot" nicolas.mailhot@laposte.net writes:
Le Lun 5 mai 2008 21:35, Hans de Goede a écrit :
Ugh, no no no, thats just ugly for no good reason, just add a Requires to the full version of the base package, or the sub-package that the sub-package needs.
That only works if you have a nice subpackage hierarchy. Not all packages are like that
Sure, but I don't think we should saddle every package with complexity that is only needed in a few special cases. My packages all have very simple subpackage structure, and AFAICS putting in Conflicts: would just be overkill.
Another possible issue is whether a Conflicts-based solution is as friendly to the depsolver. I have no idea if it's true or not, but it seems at least possible that "get me this version" is faster to solve than "don't get me this version, but you'd better find something".
regards, tom lane
Tom Lane wrote:
Another possible issue is whether a Conflicts-based solution is as friendly to the depsolver. I have no idea if it's true or not
In general, it is not, which is one reason why the current guidelines pretty much ban the explicit use of Conflicts (except for rare/exceptional cases).
-- Rex
On Mon, 2008-05-05 at 12:40 -0400, Tom Lane wrote:
Given a single SRPM generating multiple sub-RPMs, some of which depend on each other, how hard should the maintainer try to ensure that matching versions of the sub-RPMs are installed? Possible answers include:
- Do nothing, rely on automatically generated requires (eg, the major
version of a shared library's soname). Maximum flexibility, maximum possibility of allowing installations that don't actually work.
Show me a package that would break if a different version library was used that has the same soname and I'll show you a developer that needs to learn how to properly use sonames.
On Tue, 2008-05-06 at 22:31 -0400, Ignacio Vazquez-Abrams wrote:
Show me a package that would break if a different version library was used that has the same soname and I'll show you a developer that needs to learn how to properly use sonames.
Different *newer*, of course.
Ignacio Vazquez-Abrams ivazqueznet@gmail.com writes:
On Mon, 2008-05-05 at 12:40 -0400, Tom Lane wrote:
- Do nothing, rely on automatically generated requires (eg, the major
version of a shared library's soname). Maximum flexibility, maximum possibility of allowing installations that don't actually work.
Show me a package that would break if a different version library was used that has the same soname and I'll show you a developer that needs to learn how to properly use sonames.
Hmm, you think a version digit or so is enough to encode everything there is to be known about a package?
I'm using a fairly wide definition of "break" here, such as package A not having an optional capability that package B expects it to have --- in the context of the stuff I work with, a good example would be SSL support in a client library. A non-SSL-capable client could fail to interoperate with a server that was configured to demand SSL protection, or vice versa. And that would have nothing to do with whether the client library could successfully link with its calling application, which is the sum total of what the soname is expected to handle. The soname convention simply hasn't got the bandwidth to handle every possible combination of build options that a given upstream tarball might support.
In places where it really matters, we have developed conventions for Requires: symbols that can convey fine detail, for instance BuildRequires: perl(ExtUtils::Embed) But I can't see going to that much trouble for intramural dependencies among the subpackages of a single SRPM.
regards, tom lane
On Tue, 2008-05-06 at 23:01 -0400, Tom Lane wrote:
Ignacio Vazquez-Abrams ivazqueznet@gmail.com writes:
On Mon, 2008-05-05 at 12:40 -0400, Tom Lane wrote:
- Do nothing, rely on automatically generated requires (eg, the major
version of a shared library's soname). Maximum flexibility, maximum possibility of allowing installations that don't actually work.
Show me a package that would break if a different version library was used that has the same soname and I'll show you a developer that needs to learn how to properly use sonames.
Hmm, you think a version digit or so is enough to encode everything there is to be known about a package?
Think of SONAMES in terms of APIs. Two packages providing a library with the same SONAME must be API-compatible and remain API-compatible throughout a distributions life-time.
Read "info libtool" for one approach to it.
More generally speaking, version-numbers will never be enough to "encode everything ... about a package". They are a minimum, "necessary requirement" and will need to be supported by further measures.
Which, depends on your individual case. For compile time deps, "compile-time feature-checks" are an appropriate means, in other situations, you may use run-time checks, ... if all else fail, you will need to resort to "conventions".
Ralf
Ralf Corsepius rc040203@freenet.de writes:
On Tue, 2008-05-06 at 23:01 -0400, Tom Lane wrote:
Hmm, you think a version digit or so is enough to encode everything there is to be known about a package?
Think of SONAMES in terms of APIs. Two packages providing a library with the same SONAME must be API-compatible and remain API-compatible throughout a distributions life-time.
Actually, I think SONAME is supposed to promise ABI compatibility, which is not the same as API compatibility. But that's a marginal issue. The point I was trying to make is that a library can have a lot of behaviors that do not, and SHOULD NOT, involve breakage of its ABI contract; and yet can well impinge on its ability to play nice with other packages that are outside the scope of its ABI.
regards, tom lane
On Wed, 2008-05-07 at 00:46 -0400, Tom Lane wrote:
Ralf Corsepius rc040203@freenet.de writes:
On Tue, 2008-05-06 at 23:01 -0400, Tom Lane wrote:
Hmm, you think a version digit or so is enough to encode everything there is to be known about a package?
Think of SONAMES in terms of APIs. Two packages providing a library with the same SONAME must be API-compatible and remain API-compatible throughout a distributions life-time.
Actually, I think SONAME is supposed to promise ABI compatibility, which is not the same as API compatibility.
Pedantically speaking, you are right.
It's only that from a library implementor's point of view, the real ABI (Compiler, object format/ELF) must remain constant and unchanged, i.e. they use SONAMEs to version their APIs under the premise of a constant ABI.
But that's a marginal issue. The point I was trying to make is that a library can have a lot of behaviors that do not, and SHOULD NOT, involve breakage of its ABI contract; and yet can well impinge on its ability to play nice with other packages that are outside the scope of its ABI.
Ralf
packaging@lists.fedoraproject.org
-
Hans de Goede -
Ignacio Vazquez-Abrams -
Jonathan Underwood -
Nicolas Mailhot -
Ralf Corsepius -
Rex Dieter -
Tom Callaway -
Tom Lane -
Toshio Kuratomi