[Rpm-maint] [PATCH] Split the processing programs and libraries
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
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!"
- Panu -
More information about the Rpm-maint