Re: Location of executable code

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, May 22, 2020 at 09:31:25PM -0400, Steve Grubb wrote:
> My question now is how can we determine what is meant to be 
> executable by system applications vs examples and other cruft? (This might be 
> relevant to people minimizing systems/containers.)

Theoretically the examples are a documentation, and a documentation should be
marked in an RPM database with a documentation flag. RPM even has an ability
to remove the documentation files when installing an RPM package.

But the reality is that only the manual pages and the files packaged with
a %doc RPM macro are marked so. E.g. Perl POD files are not marked, because
there is no easy way of programming rpm-build to handle a custom files as
a documentation.
 
Of course these is the "other cruft" that has no flags.

Another approach is the executable bit in a file mode. But it's not applied
evenly. E.g. ELF shared libraries get the bit set, but static libraries are
missing it. Also various languages (like Perl) do not mark their libraries
(modules) with the bit. The meaning of the bit is that the file is a program
with an entry point understood by the kernel program loader. You can e.g.
program Linux to execute Windows executables by configuring binfmt_misc
properly.

So I guess you are after a yet another classification of files.

> Could we ask that all of the executable code live inside a libexec dir and
> examples under something else?

Possible, but tedious. We would need to get a consensus among muplitple
distributions and major upstreams. A decades long project. Installing files
into the unexpected paths is questionable.

Do you know about software collections (RHSCL product)? We packaged some
software under /opt at the expense that users had to set the environment
variables (PATH, LD_LIBRARY_PATH, MANPATH) to get them accessible. It was
backslahed as too obtrusive way of using a software. Here we talk about
patchnig every software to be eable to locate its files on a new location.

I think maintaining a database of files, path prefixes, files name patterns,
or some file flags in an the RPM database or extended attributes in the file
system is an easier approach. Actually extended attributes are used by
SELinux. Maybe augmenting SELinux would make sense. It already has tools for
labeling files.

-- Petr

Attachment: signature.asc
Description: PGP signature

_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux