On Sun, Feb 24, 2019 at 09:42:10PM -0500, John Harris wrote:
> On Saturday, February 23, 2019 7:21:36 PM EST Richard W.M. Jones wrote:
> > On Mon, Feb 18, 2019 at 08:26:58PM -0500, Neal Gompa wrote:
> >
> > > On Mon, Feb 18, 2019 at 6:31 PM Tom Stellard <tstellar@xxxxxxxxxx> wrote:
> > >
> > > >
> > > >
> > > > Would there be some way to opt out of this? In some cases,
> > > > %{name}-devel
> > > > Requires only %{name}-libs and not %{name}.
> > > >
> > > >
> > >
> > >
> > > Perhaps it's not obvious, but the idea here is that RPM will "sense"
> > > what the name of the subpackage it depends on is, and generate the
> > > correct strict dependency automatically.
> > >
> > > For example, foo, foo-libs, libfoobaz, and foo-devel exist, built from
> > > foo.spec.
>
> > > foo-devel requires libfoobaz.so.1 (provided by libfoobaz) and
> > > libfoo.so.0 (provided by foo-libs).
> > >
> > > Currently, rpm generates the "libfoobaz.so.1()(64bit)" and
> > > "libfoo.so.0()(64bit)" dependencies and leaves the rest to you. This
> > > will change the behavior so that when it identifies that a subpackage
> > > produced from the spec contains that dependency, it'll be replaced
> > > with a strictly versioned dep on the subpackage. So instead of
> > > "libfoo.so.0()(64bit)", it'll be "foo-libs%{?_isa} =
> > > %{version}-%{release}". And the "libfoobaz.so.1()(64bit)" dependency
> > > would be replaced with "libfoobaz%{?_isa} = %{version}-%{release}".
> >
> >
> > I'm not saying it's right or wrong (but probably it's more "right"):
> > However this does change the actual semantics, I think. I mean,
> > previously "libfoobaz.so.1()(64bit)" might have been satisfied by an
> > older -libs package, or by another package which happens to provide
> > libfoobaz.so.1. I wonder if anything relies on that?
> >
> > Rich.
> >
> >
> > > If there's no requires that matches with a provides in another
> > > subpackage that's built from the spec, rpm would not do anything, and
> > > it'll be exactly as it is now.
> > >
> > > This is merely about optimizing requires across subpackages from the
> > > same source package.
> > >
> > >
> > >
> > > --
> > > 真実はいつも一つ！/ Always, there's only one truth!
> > > _______________________________________________
> > > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
> > > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
> > > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > List Archives:
> > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o
> > > rg
> >
> > --
> > Richard Jones, Virtualization Group, Red Hat
> > http://people.redhat.com/~rjones
> > Read my programming and virtualization
> > blog: http://rwmj.wordpress.com virt-df lists disk usage of guests without
> > needing to install any software inside the virtual machine. Supports Linux
> > and Windows. http://people.redhat.com/~rjones/virt-df/
> > _______________________________________________
> > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
> > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
> > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> > https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
>
> I definitely hope there is a way to opt out, as, often, it is not required to
> have the exact same version, so long as the soname has not been bumped. There
> are very few instances that I can think of where an soname bump is not done
> when ABI changes.
>
> Though where I know that to be the case, it's *bad*, and affects many other
> things.. So I can see the reasoning.
I think the thinking is that in case of dependencies between subpackages
of the same package it's easier and safer to simply always update them
in tandem. There might be special cases (e.g. a very large data subpackage)
where it makes sense to allow more freedom, but for the great majority
of cases this kind of flexibility is not necessary. And by doing updates
in tandem, we avoid many issues where one subpackage depends on changes
in another subpackage. In fact, in don't expect changes that are not public
API to be declared in any way.
Zbyszek
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
