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

--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging

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

--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging

"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

--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging

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

--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging

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:
>
> 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.

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.

--
Ignacio Vazquez-Abrams <ivazqueznet@gmail.com>

PLEASE don't CC me; I'm already subscribed
--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging

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>

PLEASE don't CC me; I'm already subscribed
--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging

Ignacio Vazquez-Abrams <ivazqueznet@gmail.com> writes:
> On Mon, 2008-05-05 at 12:40 -0400, Tom Lane wrote:
>> 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.

> 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

--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging

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:
> >> 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.
>
> > 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


--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging

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

--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging

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


--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging