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

[Panu Matilainen]

On Sat, 30 Oct 2010, Alexey Gladkov wrote:

> The elfdeps runs only for executable files, but some
> Linux distributions, remove the executable bit from shared libraries.
> For example, a quote from debian policy:
>
> "Shared libraries should not be installed executable, since the dynamic
> linker does not require this and trying to execute a shared library
> usually results in a core dump."
>
> http://www.us.debian.org/doc/debian-policy/ch-sharedlibs.html

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.

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..). Changing that is a compatibility issue, 
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.

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. This touches one of 
the items currently missing in the new generator: the ability to /easily/ 
exclude selected bits and pieces from the dependency generation (or its 
results). I've been pondering on how to best do it for a while... Now 
that everything can be overridden by specs, it's /possible/ to weed out 
any unwanted dependencies by providing custom filter scripts for the 
attributes you want but that's not as convenient as it should be. One 
possibility is adding __foo_(pattern|magic)_exclude that takes precedence 
over the inclusive rules, but there was some issue with that too, just 
can't remember ATM what it was.

>
> Signed-off-by: Alexey Gladkov <gladkov.alexey at gmail.com>
> ---
> fileattrs/elf.attr    |    2 +-
> fileattrs/elflib.attr |    4 ++++
> 2 files changed, 5 insertions(+), 1 deletions(-)
> create mode 100644 fileattrs/elflib.attr
>
> diff --git a/fileattrs/elf.attr b/fileattrs/elf.attr
> index fba180b..7355b8f 100644
> --- a/fileattrs/elf.attr
> +++ b/fileattrs/elf.attr
> @@ -1,4 +1,4 @@
> %__elf_provides		%{_rpmconfigdir}/elfdeps --provides %{?__filter_GLIBC_PRIVATE:--filter-private}
> %__elf_requires		%{_rpmconfigdir}/elfdeps --requires %{?__filter_GLIBC_PRIVATE:--filter-private}
> -%__elf_magic		^ELF (32|64)-bit.*$
> +%__elf_magic		^ELF (32|64)-bit.* executable, .*$
> %__elf_flags		exeonly

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

> diff --git a/fileattrs/elflib.attr b/fileattrs/elflib.attr
> new file mode 100644
> index 0000000..3d7d04a
> --- /dev/null
> +++ b/fileattrs/elflib.attr
> @@ -0,0 +1,4 @@
> +%__elf_provides		%{_rpmconfigdir}/elfdeps --provides %{?__filter_GLIBC_PRIVATE:--filter-private}
> +%__elf_requires		%{_rpmconfigdir}/elfdeps --requires %{?__filter_GLIBC_PRIVATE:--filter-private}
> +%__elf_magic		^ELF (32|64)-bit.* shared object, .*$
> +%__elf_flags		%nil

Note that these need to be called %__elflib_foo for it to have the desired 
effect, the above will cause elflib and elf attributes to override each 
others definitions depending on the order they're loaded. It's of course 
another shortcoming in the configuration system that it allows such 
things... The file attributes should really be loaded and processed 
separately from the other macro configuration, with a file format of 
their own.

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.

 	- Panu -