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

Alexey Gladkov gladkov.alexey at gmail.com
Sun Oct 31 23:35:06 UTC 2010

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.

> 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

> One easy way out is to make it distro-configurable, eg something like this 
> in elflib.attr:
> %__elf_flags         %{?_executable_shared_libs:exeonly}%{nil}
> ...punting the decision to "somebody else", but dunno.

Thank you. I will correct it.

> While splitting this up, might as well disable/remove __elf_provides, as 
> the executables never provide anything elf-related (they could of course 
> provide something else through other attributes but that's "their 
> business").


> Note that these need to be called %__elflib_foo

Yes. I already found this bug.

> Also FWIW, while %__elflib_flags is subject to the compatibility 
> ponderings above just a general note: there's no requirement for 
> all the __foo_bar macros to be defined, you only need to define what's 
> relevant for that particular attribute. So you can just leave 
> %__elflib_flags out instead of defining it to %nil.


Rgrds, legion

More information about the Rpm-maint mailing list