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 Adams wrote:
> Once upon a time, Adam Jackson 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
Re: rpm AutoRequires/AutoProvides and dsos not in linker path, do we care ?
On Wed, Jun 17, 2009 at 5:45 PM, Kevin Kofler wrote: > 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
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 ?
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 ?
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 ?
On Wed, Jun 17, 2009 at 12:02:04PM -0400, 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. 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. Basically the rule should be, if a package provides something in the global name space (.so, perl module, etc.) then the RPM package should auto-Provide it. If it is kept in a private namespace (not searched by ld.so, not in perl module path, etc.) then it shouldn't add an auto-Provide. > Really we just need the moral equivalent of %exclude for autoreqprovs. That would still require manual packager intervention. It would be good to have, but I would argue that fixing the automatic stuff would be better. -- 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 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 ?
Le mercredi 17 juin 2009 à 11:49 -0500, Chris Adams a écrit : > Once upon a time, Adam Jackson 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 6:57 AM, 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. > As others have mentioned, we run into this with Perl arch-specific packages quite a bit; it's hardly unique to Perl, however. I have a packaging guideline up before the FPC as to how to handle these in a sane, consistent manner: https://fedoraproject.org/wiki/PackagingDrafts/AutoProvidesAndRequiresFiltering Ville was kind enough to cite this guideline's alternate incarnation as a feature, as well as the thread over on the packaging list about all this (citing here just for completeness): http://thread.gmane.org/gmane.linux.redhat.fedora.extras.packaging/5854 https://fedoraproject.org/wiki/Features/BetterRpmAutoReqProvFiltering I'd hoped this would be discussed again at yesterdays FPC meeting, but there didn't seem to be one... (Right?) -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
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 ?
Once upon a time, Adam Jackson 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 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, 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. Really we just need the moral equivalent of %exclude for autoreqprovs. - ajax signature.asc Description: This is a digitally signed message part -- 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 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. -- Chris Adams 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 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, Chuck Anderson 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 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, Caolán McNamara 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 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
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
