One nice thing on Windows is the ability to see useful metadata in the "properties" of a DLL. I think executables and libraries on Linux should have this feature too.
The ELF approach
It seems to me there should be an ELF section with arbitrary name/value pairs, and some of the names should be standardized so that they can be displayed in file managers like Nautilus, Konqueror etc.
This has already been done for kernel modules, e.g.
[i7][02:03:30 PM] modinfo /lib/modules/2.6.36-ck/kernel/lib/libcrc32c.ko filename: /lib/modules/2.6.36-ck/kernel/lib/libcrc32c.ko license: GPL description: CRC32c (Castagnoli) calculations author: Clay Haapala <email@example.com> depends: crypto_hash vermagic: 2.6.36-ck SMP preempt mod_unload
Here's some info about that.
[i7][02:10:54 PM] objdump --full-contents --section=.modinfo /lib/modules/2.6.36-ck/kernel/lib/libcrc32c.ko /lib/modules/2.6.36-ck/kernel/lib/libcrc32c.ko: file format elf64-x86-64 Contents of section .modinfo: 0000 6c696365 6e73653d 47504c00 00000000 license=GPL..... 0010 00000000 00000000 00000000 00000000 ................ 0020 64657363 72697074 696f6e3d 43524333 description=CRC3 0030 32632028 43617374 61676e6f 6c692920 2c (Castagnoli) 0040 63616c63 756c6174 696f6e73 00000000 calculations.... 0050 00000000 00000000 00000000 00000000 ................ 0060 61757468 6f723d43 6c617920 48616170 author=Clay Haap 0070 616c6120 3c636861 6170616c 61406369 ala <chaapala@ci 0080 73636f2e 636f6d3e 00000000 00000000 sco.com>........ 0090 00000000 00000000 00000000 00000000 ................ 00a0 64657065 6e64733d 63727970 746f5f68 depends=crypto_h 00b0 61736800 00000000 00000000 00000000 ash............. 00c0 7665726d 61676963 3d322e36 2e33362d vermagic=2.6.36- 00d0 636b2053 4d502070 7265656d 7074206d ck SMP preempt m
So there we go... seems that it's probably possible to do the same thing with any shared object, but I think I would choose ".metadata" instead of ".modinfo" just in case there are tools which assume that anything with a .modinfo section is really a kernel module, and also to make it clear that any kind of metadata that you like can be stored there.
Alternatively if filesystems and file-management tools (tar, cp etc.) evolve to handle metadata robustly, this info could just be stored on the filesystem - in the resource fork, if implemented that way. The trouble with resource forks is that they have to be moved along with the file, so every tool that is routinely used for file management has to support it.