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.
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.
(In reply to Ulrich Müller from comment #1) > 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. The problem with this approach is that, especially for -bin packages, determining which files require the executable bit can become either a tedious manual task required on every bump or a rather complex logic to automatically collect and doexe the files. > There are 3 executable bits, would all of them be preserved, I can not think of a reason why not. > 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 655 Or is there an reason it shouldn't be 655 if you explicitly requested to preserve the executable bit with -x? (BTW: what is the use case for 655 compared to 755?)
I see two different scenarios suggested here: 1. "conditionally use exeopts over insopts" suggested in comment #0 2. preserve all mode bits (IIUC that was suggested in comment #2) Which one do we want? Questions/problems: For option 1., how would we decide whether to use insopts or exeopts for any particular file? Based on u+x, g+x, o+x or all three of them? For option 2., would also the setuid, setgid and sticky bits be preserved? What about directories? Why is a helper even needed for doing a simply copy, can't "cp -R" be used?
(In reply to Ulrich Müller from comment #3) > For option 1., how would we decide whether to use insopts or exeopts for any > particular file? Based on u+x, g+x, o+x or all three of them? Plus, if we use exeopts for part of the files, should we then also use exeinto (instead of insinto) for their destination? It feels like we are overloading the doins helper with additional and confusing semantics. In case 1 we would be mixing in elements of doexe. In case 2 the PM would have to read the file mode, only to pass it on to the install(1) command; alternatively, it would have to avoid install and use (e.g.) cp instead.
