libexec and multi-arch

Jeff Johnson n3npq at me.com
Mon Feb 12 04:10:44 CET 2018



> On Feb 5, 2018, at 5:46 PM, Tomasz Pala <gotar at polanet.pl> wrote:
> 
> On Mon, Feb 05, 2018 at 15:20:55 -0500, Jeff Johnson wrote:
> 
>>> No, it only hidden the problem behind getconf binary being handled
>>> _somehow_. I once even wondered how this is done, apparently rpm is
>>> trying to be way too smart.
>> 
>> RPM implements arch specific content generally as:
>>  Libraries on different paths.
>>  Executables on same path.
> 
> libexec directory should be treated as binaries, not libraries (even if
> technically some of the contents are libraries, like plugins) nor data,
> as the purpose of this is to carry private helpers of the binaries, not
> any shared code.
> 
>> This requires a resolution to a preferred arch (usually x86_64) when installing executables onto identical paths.
> 
> 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.

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.

> How to extend this to all the files in mandir maybe?
> 

There are no elf files in mandir, so an extension of what rpm does makes no sense.

Meanwhile there are many conventions to extend man pages, in subdirectories, and with suffixes, that can be used if necessary.

>> Whether RPM is too smart or the requested implementation is insufficiently general is arguable. For example, one might desire the ability for per-file-path configurable choice of architecture rather than per-system confIguration.
> 
> Or - to always use preferred arch, for ANY file that is overlapping in
> packages that differ only in arch, e.g. /etc or anything inside datadir.
> 

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.

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

hth

73 de Jeff
> -- 
> Tomasz Pala <gotar at pld-linux.org>
> _______________________________________________
> pld-devel-en mailing list
> pld-devel-en at lists.pld-linux.org
> http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


More information about the pld-devel-en mailing list