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.
--
John M. Harris, Jr. <johnmh@xxxxxxxxxxxxx>
Splentity
https://splentity.com/Attachment:
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ 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
