[Rpm-maint] How to prevent rpmbuild from including dependencies on non-rpm libraries
Paul Nasrat
pnasrat at redhat.com
Fri Feb 9 10:44:00 UTC 2007
On Wed, 2007-02-07 at 12:48 -0500, James Olin Oden wrote:
> On 2/7/07, Michael Schroeder <mls at suse.de> wrote:
> > On Wed, Feb 07, 2007 at 11:54:52AM -0500, James Olin Oden wrote:
> > The problem with runtime probes is that they don't stop you from
> > deleting packages that other packages still depend on.
> >
> Yeah, there are many problems, but ultimately its a philisophical
> issue. I personally, never ever want runtime probes, because
> something that is found that is not listed as a provides (whether auto
> or otherwise) in the systems package set is a failure on my part to
> properly manage the systems configuration.
I tend to agree that's the policy that works for a distribution where
all package management is done through the system tool of choice.
> Yes I am anal. But with some folks if its their on the system, then
> from their stand point the dependency is provided for. Its a valid
> view, its just not a choice I would make.
It's also true of cases like RPM in conjunction with other package
managements (eg SysV packages). In which case the idea that RPM should
make it easy to get things in and out of the system sounds like their
may be people who desire this and are currently using other techniques
(vpkgs) to fulfil their needs.
I think runtime probes/provides might work best if we had a module or
plugin type system, with some default modules to provide existing
functionality. This is going to require some thought towards having a
flexible enough API and also other implications such as security.
> On the other hand their are some run time probes that I do
> like, but these are usually in areas like getconf values, or things
> like versions of BIOS's or hardware configurations that just won't be
> available in the package database or shouldn't be. Even then I'm
> hesitant. That said, I still think for some people this is a powerful
> feature, and if they want to manage their systems that way, I'm
> willing for them to have that choice.
Having a modular system would allow tuning of your policy to enable
this, obviously we'd need to think about the implications of a package
with a runtime dep where the probe is disabled.
I think to some extent Jeff's runtime probes uses macros to achieve
modularity and policy somewhat (eg using soft requires) and he's talked
about dlopen in the past as how to remove SELinux from RPM internally, I
think various points in RPM could benefit from a module approach to
enable flexible policies.
Paul
More information about the Rpm-maint
mailing list