Re: rpm AutoRequires/AutoProvides and dsos not in linker path, do we care ?
Adam Jackson wrote: On Wed, 2009-06-17 at 10:06 -0400, Chuck Anderson wrote: On Wed, Jun 17, 2009 at 02:57:53PM +0100, Caolán McNamara wrote: b.2) extend the autorequires/autoprovides in some (handwaves) way to better indicate the desired match I like this idea better. AutoReq/Prov should only search system-wide deafult search paths for .so's, perl modules, and any other such objects that it supports. system-wide includes paths mentioned in /etc/ld.so.conf.d/*, which are files provided by other packages. Suddenly your search scope is unbounded again. Thought: Define system library directories to a sane default set. Start with this. For each package, when doing autoprovides calculation, recurse down the tree of rpms needed by this package. For any that change /etc/ld.so.conf.d, add the appropriate directory to the set of system library directories. Now see if the rpm installs any libraries into those locations. If so, those are autoprovides. Sound sane? -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- XFS is not something I look into the innards of, as I don't have enough chickens to sacrifice. -- Alan Cox -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rpm AutoRequires/AutoProvides and dsos not in linker path, do we care ?
On Wed, Jun 17, 2009 at 6:49 PM, Chris Adamscmad...@hiwaay.net wrote:
Once upon a time, Adam Jackson a...@redhat.com said:
Really we just need the moral equivalent of %exclude for autoreqprovs.
Yeah, I said that years and years ago, but RPM didn't want it.
Just for info, PLD some time ago have included a run-time dependency
filtering in RPM
that don't break file-color dependency for multilib system. Some other RPM fork
had already included it.
Here, an examples from opera
...
%prep
%ifarch %{ix86}
%if %{with qt4}
%setup -q -T -b 13 -n %{name}-%{version}-%{buildid}.gcc4-qt4.i386
%define _noautoreq 'libpng12.so.0(.*)'
%else
...
that filter matching Requires. This PLD patch provide also _noautoprov
and _noautoreqfiles.
The good thing, for someone almost, is that the filtering is possible
globally for platform and not in unportable way between distro in the
SPEC file.
Regards
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
rpm AutoRequires/AutoProvides and dsos not in linker path, do we care ?
So, https://bugzilla.redhat.com/show_bug.cgi?id=502226 was logged a while ago against OOo for the rpms improperly providing and requiring .sos that are not in the linker path, but instead in OOo's own subdirs. The concern is that the autorequires/provides operate in a flat namespace and that eventually there'll be some conflation where something linking to /usr/lib/foo.so will force sucking in a package that provides /usr/lib/package/plugins/foo.so instead Clearly this isn't specific to OOo, e.g. as a random example $ rpm -q --provides gedit|grep spell libspell.so $ rpm -ql gedit | grep libspell.so /usr/lib/gedit-2/plugins/libspell.so and probably thousands of others. So, a) do we care ? b) if we care do we want to b.1) make every package that has some shared libraries in it that are not in the default linker path make manual filters to exclude the provides/requires ? (oh, the pain) b.2) extend the autorequires/autoprovides in some (handwaves) way to better indicate the desired match C. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rpm AutoRequires/AutoProvides and dsos not in linker path, do we care ?
Once upon a time, Caolán McNamara caol...@redhat.com said: The concern is that the autorequires/provides operate in a flat namespace and that eventually there'll be some conflation where something linking to /usr/lib/foo.so will force sucking in a package that provides /usr/lib/package/plugins/foo.so instead It has happened with perl modules already. mrtg has a private copy of the perl SNMP_Session, SNMP_util, and BER modules (all from SNMP_Session) and auto-provided them. Since mrtg is shorter than perl-SNMP_Session, mrtg was chosen to provide those dependencies, which didn't work. mrtg is still auto-providing a bunch of internal modules; only the SNMP_Session modules were filtered out. That's just one I've personally had to deal with. In a perfect world, the solution would be something along the lines of: - generate the auto-provides for system directories separate from package-provided directories - generate the auto-requires - filter everything auto-provided from package-provided directories out of both the provides and requires I'm sure that would still break something though. You'd have to have a way to flag additional directories as system for packages that extend the system directories list (e.g. by dropping something in /etc/ld.so.conf.d). -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rpm AutoRequires/AutoProvides and dsos not in linker path, do we care ?
On Wed, Jun 17, 2009 at 02:57:53PM +0100, Caolán McNamara wrote: So, https://bugzilla.redhat.com/show_bug.cgi?id=502226 was logged a while ago against OOo for the rpms improperly providing and requiring .sos that are not in the linker path, but instead in OOo's own subdirs. a) do we care ? Yes I care. I ran into somthing similar for perl modules. Packages shouldn't provide 'perl(foo)' unless those modules are in perl's default module path. It clearly breaks programs when a perl module in a private directory satisfies an rpm dependency for another package. b) if we care do we want to b.1) make every package that has some shared libraries in it that are not in the default linker path make manual filters to exclude the provides/requires ? (oh, the pain) That is what I had to do in the case of a perl program I'm packaging. There are even Fedora guidelines on how to do this for perl. b.2) extend the autorequires/autoprovides in some (handwaves) way to better indicate the desired match I like this idea better. AutoReq/Prov should only search system-wide deafult search paths for .so's, perl modules, and any other such objects that it supports. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rpm AutoRequires/AutoProvides and dsos not in linker path, do we care ?
Once upon a time, Chuck Anderson c...@wpi.edu said: b.2) extend the autorequires/autoprovides in some (handwaves) way to better indicate the desired match I like this idea better. AutoReq/Prov should only search system-wide deafult search paths for .so's, perl modules, and any other such objects that it supports. That breaks things, because a program in /usr/bin may require a module or library in a private directory. You have to search all directories for provides to satisfy internal requires. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rpm AutoRequires/AutoProvides and dsos not in linker path, do we care ?
On Wed, Jun 17, 2009 at 09:42:38AM -0500, Chris Adams wrote: Once upon a time, Chuck Anderson c...@wpi.edu said: b.2) extend the autorequires/autoprovides in some (handwaves) way to better indicate the desired match I like this idea better. AutoReq/Prov should only search system-wide deafult search paths for .so's, perl modules, and any other such objects that it supports. That breaks things, because a program in /usr/bin may require a module or library in a private directory. You have to search all directories for provides to satisfy internal requires. If a program in /usr/bin requires something in a private, non-system directory that is provided by a different package, then the provides/requires need to express that somehow, perhaps by using a full path in the provides. Until that becomes possible, I'm inclined to say that AutoReq/Prov shouldn't be searching private directories, and we should require all packages that have such requirements to use manual Requires: on either the file path or the package that provides the private library. Keeping things the way they are now is just plain broken. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rpm AutoRequires/AutoProvides and dsos not in linker path, do we care ?
Once upon a time, Adam Jackson a...@redhat.com said: Really we just need the moral equivalent of %exclude for autoreqprovs. Yeah, I said that years and years ago, but RPM didn't want it. Having many many packages with their own hacked versions of scripts to exclude autoreqprovs is silly (and a maintenance mess). -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rpm AutoRequires/AutoProvides and dsos not in linker path, do we care ?
On Wednesday 17 June 2009, Adam Jackson wrote: Really we just need the moral equivalent of %exclude for autoreqprovs. http://thread.gmane.org/gmane.linux.redhat.fedora.extras.packaging/5854 https://fedoraproject.org/wiki/Features/BetterRpmAutoReqProvFiltering -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rpm AutoRequires/AutoProvides and dsos not in linker path, do we care ?
Le mercredi 17 juin 2009 à 11:49 -0500, Chris Adams a écrit : Once upon a time, Adam Jackson a...@redhat.com said: Really we just need the moral equivalent of %exclude for autoreqprovs. Yeah, I said that years and years ago, but RPM didn't want it. Having many many packages with their own hacked versions of scripts to exclude autoreqprovs is silly (and a maintenance mess). File triggers are based on the same idea. -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rpm AutoRequires/AutoProvides and dsos not in linker path, do we care ?
On Wed, Jun 17, 2009 at 11:00:06AM -0500, Chris Adams wrote: Once upon a time, Chuck Anderson c...@wpi.edu said: On Wed, Jun 17, 2009 at 09:42:38AM -0500, Chris Adams wrote: That breaks things, because a program in /usr/bin may require a module or library in a private directory. You have to search all directories for provides to satisfy internal requires. If a program in /usr/bin requires something in a private, non-system directory that is provided by a different package, then the provides/requires need to express that somehow, perhaps by using a full path in the provides. I was talking about in the same package. For example, MRTG installs in /usr/bin/mrtg, and then needs private perl modules. If you simply remove the private directories, you'll end up with broken dependencies because /usr/bin/mrtg needs modules that are not provided anywhere. I don't see why. You would obviously filter out the Requires as well as the Provides. Those files are in the same package as the binary, so they'll always be there when the package is installed. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rpm AutoRequires/AutoProvides and dsos not in linker path, do we care ?
Chris Adams wrote: It has happened with perl modules already. mrtg has a private copy of the perl SNMP_Session, SNMP_util, and BER modules (all from SNMP_Session) That's the real problem, apps are not supposed to ship private copies of system libs in the first place, it needs to be fixed to use the system libraries. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rpm AutoRequires/AutoProvides and dsos not in linker path, do we care ?
Chuck Anderson (c...@wpi.edu) said: system-wide includes paths mentioned in /etc/ld.so.conf.d/*, which are files provided by other packages. Suddenly your search scope is unbounded again. Not really unbounded. If a package puts a file in /etc/ld.so.conf.d/ then the library is now available system-wide, so it should be searched by autorequires/autoprovides. The package that puts the file in ld.so.conf.d and the package that puts libraries into the location specified in that file may not be the same package, and actually may have no dependencies between them at all... Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rpm AutoRequires/AutoProvides and dsos not in linker path, do we care ?
On Wed, Jun 17, 2009 at 10:50:43PM -0400, Bill Nottingham wrote: Chuck Anderson (c...@wpi.edu) said: system-wide includes paths mentioned in /etc/ld.so.conf.d/*, which are files provided by other packages. Suddenly your search scope is unbounded again. Not really unbounded. If a package puts a file in /etc/ld.so.conf.d/ then the library is now available system-wide, so it should be searched by autorequires/autoprovides. The package that puts the file in ld.so.conf.d and the package that puts libraries into the location specified in that file may not be the same package, and actually may have no dependencies between them at all... Do we have any examples of that? I'd be inclined to say if there are a very few cases where one package provides an ld.so.conf.d file that ends up being used by many other packages, we should just put that path into the system default /etc/ld.so.conf, so it is always present. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rpm AutoRequires/AutoProvides and dsos not in linker path, do we care ?
On Wed, Jun 17, 2009 at 5:45 PM, Kevin Kofler kevin.kof...@chello.atwrote: Chris Adams wrote: It has happened with perl modules already. mrtg has a private copy of the perl SNMP_Session, SNMP_util, and BER modules (all from SNMP_Session) That's the real problem, apps are not supposed to ship private copies of system libs in the first place, it needs to be fixed to use the system libraries. There are two problems here, one fixed: 1) mrtg should look at using the perl modules provided by perl-SNMP_Session, and 2) mrtg must not provide perl dependency info where the Perl modules are outside the system Perl library paths (that is, @INC). -Chris -- Chris Weyl Ex astris, scientia -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
