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.
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
