Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 566762 - fowners arguments are not specified
Summary: fowners arguments are not specified
Status: CONFIRMED
Alias: None
Product: Gentoo Hosted Projects
Classification: Unclassified
Component: PMS/EAPI (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: PMS/EAPI
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-11-25 00:02 UTC by SpanKY
Modified: 2023-04-28 09:23 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description SpanKY gentoo-dev 2015-11-25 00:02:21 UTC
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
Comment 1 Ulrich Müller gentoo-dev 2015-11-25 01:40:03 UTC
Instead of explicitly specifying arguments, I'd rather say something like "accepts the same options and operands as POSIX chown".
Comment 2 Ulrich Müller gentoo-dev 2015-11-25 01:45:07 UTC
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."
Comment 3 SpanKY gentoo-dev 2015-11-25 03:38:51 UTC
as i mentioned though, we already rely on an extension not in POSIX: changing just the group and not the user
Comment 4 Ulrich Müller gentoo-dev 2015-11-25 07:15:26 UTC
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.
Comment 5 SpanKY gentoo-dev 2015-11-26 07:12:53 UTC
(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.
Comment 6 Ulrich Müller gentoo-dev 2015-11-26 08:15:50 UTC
(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?
Comment 7 SpanKY gentoo-dev 2015-11-26 11:00:46 UTC
(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.
Comment 8 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2015-11-26 11:29:30 UTC
What do you mean by sane? -P? I don't really see a reason to follow symlinks when explicitly working on install tree.
Comment 9 Ulrich Müller gentoo-dev 2015-12-12 23:02:12 UTC
(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.
Comment 10 Ciaran McCreesh 2015-12-23 17:55:57 UTC
This whole discussion is basically pointless unless Portage checks the arguments and enforces them...