[Rpm-maint] [PATCH] Split the processing programs and libraries

Panu Matilainen pmatilai at laiskiainen.org
Thu Nov 11 09:52:48 UTC 2010

Meh, I've been writing a reply to this, getting interrupted, forgetting, 
continuing writing, getting interrupted ... etc.

On Mon, 1 Nov 2010, Alexey Gladkov wrote:

> 31.10.2010 13:57, Panu Matilainen wrote:
>> No objections to splitting elf libraries to a separate "class" as such,
>> in fact this is one of the things I had in mind with the new dep
>> generator: enabling much more finer grained handling of different file
>> types. The same thing largely applies to interpreted languages too,
>> executables and libraries are quite different beasts and typically require
>> rather different handling. Changing that is a compatibility issue,
> This is great news for me :)
>> Removing the executability requirement is a bit touchier subject though:
>> the executable bit is what rpm has traditionally (as in, always) used for
>> determining whether dependency exctraction should be performed on a file
>> or not (of course there are already several exceptions to that,
>> like perl and python modules..).
> I think this is true, but not for libraries. Because all the shared
> libraries should be generate the dependencies as well as all
> executable binaries.
> When the program without a executable bit, then no easy way to run it.
> However, the linker will use the library even without a executable
> bit. So, if a program is linked with the shared library without a
> executable bit, then rpm package containing the program receives an
> unmet dependency.

Indeed. Like said it's the way it is mostly because there hasn't been 
other reasonable way of selectively disabling/filtering dependency 
generation on given files.

>> people are using it do selectively disable dependency generation on eg
>> private library modules. Which is not a particularly good mechanism,
>> there just hasn't been any better way to generally do it.
> I think that the library depending should be generated only when it is
> the standard path e.g. /lib(64)?, /usr/lib(64)? ... and of course
> should be mechanism to add some directory to this list.
> The fact that now the dependence is generated for all elf files, but
> not all this files are libraries or programs. There is one more class
> files - plugins and modules. The programs don't link with them and use
> it in runtime. Usually they don't have a SONAME. These plugins are
> usually located in the subdirectories and do not need to generate for
> them.

Even plugins/modules can (and often do) have dependencies to whatever 
libraries they link to, and those requires do need to be collected. DSO's 
that are only ever opened runtime shouldn't provide anything, the problem 
is knowing what is a module/plugin and what's not. Using SONAME existence 
for determining it is unfortunately way too unreliable - libraries are not 
required to have a soname and modules/plugins are permitted to have a 
soname even if they really shouldn't.

So in practise, something else is needed. One common case of these is 
python/perl/whatever language extension modules - they want requires 
generation but no provides should be emitted for such dso's. One 
possibility could be allowing file attributes to interact a bit, so you 
could add eg python_ext.attr which flags *.so files in the python library 
paths with a special "module" attr/flag that the elflib stuff would know 
to skip for provides.

Another problem with application private libraries is that while they want 
requires generation too, they might link to other private libraries as 
well as system libraries.. and you'd probably want to filter the 
application private library dependencies out while still getting the 
system lib dependencies. It's just that the elfdep generator hasn't really 
got a clue what's going to provide something, so the best we could do is 
have some nice way for to express it in spec files.

Ideas are welcome. I've some of my own but haven't got that "Eureka!" 
moment yet...

 	- Panu -

More information about the Rpm-maint mailing list