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

[Mark Hatle]

On 10/31/10 6:35 PM, 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.
>
>> 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.

Just using the items from the standard library directories is not enough. 
Between programs that add components to ld.conf, and other programs that have 
rpath or similar usage.. this is problematic.

It really does need to scan everything in the system and return back full 
results.  With a way to selectively disable a file, or dependency.

--Mark

>> 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").
>
> Yes.
>
>> 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.
>
> Ok.
>