|Summary:||[Future EAPI] doins: support preserving executable bits|
|Product:||Gentoo Hosted Projects||Reporter:||Michał Górny <mgorny>|
|Package list:||Runtime testing required:||---|
|Bug Depends on:|
Description Michał Górny 2019-06-19 12:12:40 UTC
I'm seeing a repeating scenario of people wanting to use 'doins -r' to install whole package tree, e.g. into /opt or /usr/lib/foo. This frequently involves files with executable bits that currently are not preserved. This frequently gives birth to ugly hacks, from splitting install into separate doins+doexe parts, to running loops to collect and doexe files that are executable in source tree. I think we should either modify 'doins -r' to preserve executable bits (the way e.g. git does), or possibly add a new option to enable this behavior. In this case, it would probably have to conditionally use exeopts over insopts.
Comment 1 Ulrich Müller 2019-09-30 09:08:45 UTC
There are 3 executable bits, would all of them be preserved, and how would this interact with insopts and exeopts? For example, if my tree contains a file with mode 0655, what would be the mode of the installed file after: insopts -m 0644 exeopts -m 0754 doins -rx foo I'd rather say that people should use regular doins -r followed by fperms on any files that should be executable. This has the advantage that it is explicit and doesn't rely on mode bits in the upstream tarball.