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 <go...@pld-linux.org> _______________________________________________ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
