libexec and multi-arch

[Tomasz Pala]

On Sun, Feb 11, 2018 at 22:10:44 -0500, Jeff Johnson wrote:

>> How is rpm recognizing files that are subject to this special-handling
>> as same-path-executables?
> 
> RPM reads elf headers and sets a per file color flag in metadata:
>     0==no arch or not elf
>     1==elf32
>     2==elf64
>     4== mostly unused, except on big endian mips
> Bits were used instead of an enum in case some idiot decided to put both elf32 and elf64 in the same static archive.

OK, so it is really just being too smart. If it happens, that there
are some simple sh-scripts in %_bindir, they won't be colored and
so the multilib would require general-rules approach (the same file
content or prepare for conflict).

> Choosing between multiple files with different flags but identical paths is computed during install, and the preferred arch is used while other files are marked "wrong color" and not installed
> 
>> How to extend this to all the files inside libexecdir?
> 
> There's nothing to extend: the confusion comes from mixtures of libraries/modules/executables in libexecdir, not anything else.

I would explain this to you, but having a history of conversations in
mind I know this is pointless. So thank you for response to all my
questions.

> That is essentially what is implemented in rpm for files from different arch (technically "color" as in elf32 or elf64) that are on the same path.

I just wanted the colors to be used without elf headers.

But I guess this is simply another misdesign choice for the colors to be
inheritly connected with specific _file_ architecture, not entire
_package_ architecture (at least as a fallback), so for non-ELF files rpm is simply not going to
be a help.

>> Currently, if such files exist, they need to have identical content for
>> the packages to be installed simultaneously, or be separated into
>> respective subpackages, which is unnecessary maintenance burden.
> 
> Um, I'm not sure how rpm is responsible for packaging policies (like separated into sub packages) or maintenance burden.

Who says about responsibility? It simply doesn't help solving such cases.
And since they are happening frequently, this enforces to create some
decent packaging policy. It would be much better to solve this in some
single central tool, but there is no good package manager for Linux for
now, so we have to use what we have. I hope there would be some 21st
century package manager some day, handling ACLs, xattrs, file-versioning
etc.

-- 
Tomasz Pala <gotar at pld-linux.org>