[Rpm-maint] Pruning self-dependencies?

[Mark Hatle]

Panu Matilainen wrote:
> On Mon, 9 Jul 2007, Mark Hatle wrote:
> 
>> You are forgetting that you can query per file dependencies in modern
>> RPM produced packages.  If you prune self-provided dependencies you lose
>> this information.
>>
>> --filerequires and --fileprovides.  Invaluable in my experience.
> 
> Heh, I'd never noticed rpm *had* such options...
> 
> I can see how those are useful for some purposes such as digging out
> where exactly some dependency bloat comes from. Pruning self-requires
> wouldn't affect the utility of that much I think.
> 
> This actually makes me think it'd be nice if there was a tool for
> running the internal dependency generator on arbitrary files (outside
> rpmbuild) so you could look at any file/filelist and see how rpm
> classifies them and what dependencies it'll produce.
> 
>> There just is no reason to prune self-fulfilled dependencies.
> 
> Saving memory and bandwith is "no reason"?

I'm very conscious of memory and bandwidth.  But frankly, I don't see
these as heavy in either category.  For a FULL distro the size of
Fedora, they might amount to a few megabytes.. but having the info
outweighs the size IMHO.

> Out of curiosity, what exactly do you use those --filerequire and
> --fileprovide options for? Like said, I can see some purposes where they
> can be useful but it's not like they're required for average every day
> operation :)

We and others use these options specifically for partial package
installations.  We also use it for doing dependency graphs on files.  We
ship embedded distributions so dependencies are a big deal for us, as
well as the ability to determine why things are coming in.  For some
uses the package's dependencies are not the correct granularity for us,
but file dependencies are.

For a typical workstation/server use, I agree.. per file dependencies
are more of a debug tool or query tool.  For an embedded system.. they
are essential to development of a product using standard package containers.

--Mark

>     - Panu -