PMS merely says wrt fowners: fowners: Acts as for chown, but takes paths relative to the image directory. for other programs in this section, it's implied that they take no arguments (although it also does not explicitly state that when it should). the problem is that ebuilds have long used options like -R -L -H --dereference, and out of order (options after files), so we're to presume that any flag is valid. but then we're tied to a specific chown implementation (GNU in this case) rather than something more desirable (like POSIX). some people even use the syntax `chown :group` which POSIX doesn't permit, but at least GNU implements. we should specify the behavior explicitly: * fowners [-h|-H|-L|-P|-R] <owner[:group]|:group> <file> [files] http://pubs.opengroup.org/onlinepubs/9699919799/utilities/chown.html
Instead of explicitly specifying arguments, I'd rather say something like "accepts the same options and operands as POSIX chown".
Or even, one global notice: "Except where otherwise noted, system commands mentioned in this specification must support all forms of invocations specified by POSIX.1‐2008."
as i mentioned though, we already rely on an extension not in POSIX: changing just the group and not the user
fowners is only a wrapper around chown. Except for prefixing paths with ED all parameters are simply passed on, so the spec needs to say what is required for chown. As I see it, we have three choices here: 1. Require POSIX chown. 2. Require chown from some version of GNU coreutils. This would need an EAPI bump (similar as we have done for GNU find). 3. Say that the ebuild must make sure that all parameters are supported by the chown implementation on every keyworded arch. Which really goes without saying.
(In reply to Ulrich Müller from comment #4) the problem with (3) is that there is more than one chown implementation. if you want to leave past EAPIs more or less undefined, then so be it, but there's no reason to not specify it for future ones. history has shown that there's not a whole lot that ebuilds actually care about: (1) flags POSIX provides (with -R being 99% of them) (2) ability to change just the group (a GNU extension) from there it's fairly trivial to define it as i already did in comment #0, and for people to implement that spec directly (in python or C++ or whatever) if they don't want to provide GNU chown. considering the simplicity of the spec, just saying "use GNU chown" is overkill here.
(In reply to SpanKY from comment #5) > (1) flags POSIX provides (with -R being 99% of them) chown on HP-UX seems to support only -h and -R, but not the other POSIX options. However, I see only a single ebuild in the tree that uses anything else than -R (media-fonts/acroread-asianfonts-9.1, and it does fowners -R -L --dereference which is outside of POSIX anyway). > (2) ability to change just the group (a GNU extension) Solaris, AIX, and HP-UX don't support changing the group alone. So if we are going to give up the idea that fowners is a wrapper and explicitly specify options instead, then I'd go for something simple like this: fowners [-R] owner[:group] file... fowners [-R] :group file... For the second form, fowners would call chgrp instead of chown, I suppose?
(In reply to Ulrich Müller from comment #6) if we're going to spend the time on fully specing it out, i think we should include sane symlink handling from the start. it's in POSIX and implementing it isn't that hard. wrt handling of :group, a wrapper could just call chgrp instead on the group.
What do you mean by sane? -P? I don't really see a reason to follow symlinks when explicitly working on install tree.
(In reply to Michał Górny from comment #8) > What do you mean by sane? -P? I don't really see a reason to follow symlinks > when explicitly working on install tree. I suggest that we follow the default behaviour of GNU chown(1). Namely, dereference symlinks specified on the command line, but don't follow symlinks when recursively traversing directories. This would also be consistent with what fperms/chmod does.
This whole discussion is basically pointless unless Portage checks the arguments and enforces them...
