Users upgrading to push-2.0-r1 will observe a complete breakage of their scripts when they use the script in the documented way by executing it, because it is no longer in /usr/bin due to the "fix" of bug 598527. If you (i.e. gentoo) strictly refuse to install a working variant of the package (i.e. into /usr/bin) I see the following options: 1. Introduce USE=vanilla to allow users a working installation. 2. Rename the package into e.g. push-shim or push-gentoo so that users do not get the wrong impression that the upstream package is actually installed and might be working as documented (by upstream). In this case, please also install a README which makes this clear explicitly. I strongly hope that you choose one of these options (preferrably the first), because it corresponds to the gentoo philosophy to give users a choice: In this case between having a practically working package according to the upstream documentation or something "theoretically nice" but practically broken, i.e. only working when used with scripts patched to work in a distribution-specific way. To avoid such incompatibilities of shells/distributions is exactly one of the main purpose of the package; when installing the package not in /usr/bin, it completely looses its purpose. If you agree with neither, I kindly ask you to remove my package from the gentoo repository. The same bug holds for app-shells/quoter (quoter_pipe.sh) and app-portage/eix (eix-functions.sh). If you prefer, I can open separate bugs for each of these packages, but perhaps it is more convient to handle the same issue for all together in this single bug.
(CC-ing qa@ since the change was done on behalf of QA) Yeah, I agree we should kill those useless scripts. Possibly shove them into app-portage/eix and forget about them.
It has some elegance to just call ". quoter_pipe.sh", but $PATH is not intended for source-able shell fragments. We discussed with QA in #-dev and decided to put that stuff into /usr/share/${PN}. I'd suggest to update package documentation and require users to ". /usr/share/quoter/quoter_pipe.sh". (In reply to Michał Górny from comment #1) > Yeah, I agree we should kill those useless scripts. Possibly shove them into > app-portage/eix and forget about them. These scripts are note useless, they can reside somewhere outside $PATH, imho.
(In reply to Michał Górny from comment #1) > useless scripts The true motivation is shown. > Possibly shove them into app-portage/eix This package is concerned as well, because of eix-functions.sh not being available for user scripts anymore as documented. (In reply to Michael Weber from comment #2) > I'd suggest to update package documentation I had thought for a long time before I decided that having it in PATH is the only reasonable way: It is completely pointless to require the consumer of the script to write system-specific code only to use a few lines of code whose main purpose it is exactly to be _not_ system specific (e.g. to not use system-specific printf %q, IFS=$'\0', or arrays available only in some shells). I am not going to cripple my projects because of a misguided decision of a distribution. > but $PATH is not intended for source-able shell fragments We are speaking about an executable which is documented to be used (and actually is used) as an executable which happens to _output_ shell fragments. Intended by whom? And what has QA to do with this? Which quality is in danger if an executable is in the PATH which explicitly is meant to be in PATH and, moreover, which _has_ to be in PATH when it should be used as intended?
All that was discussed at length in bug 493000 and bug 598527 and I don't expect any new facts to pop up here. QA's assessment is that sourceable shell scripts are to be installed in /usr/lib or (if they are architecture-independent) in /usr/share. (In reply to Michael Weber from comment #2) > I'd suggest to update package documentation and require users to > ". /usr/share/quoter/quoter_pipe.sh". +1
(In reply to Ulrich Müller from comment #4) > All that was discussed at length Indeed, I do not want to repeat that nonsense discussion. > QA's assessment There is still not a single technical argument which quality is in danger. Currently, the only quality "improvement" consists in: 1. Certainly breaking existing user scripts. 2. Refusing to install projects such that they work as documented. 3. Suggesting upstream to recommend users to write gentoo-specific workarounds for 2. Implicitly, also users are forced to mount /usr/share noexec (or even more specific workarounds are required for testing availability) because of the poor choice of the path, but I consider this point already nonessential. I made clear in my first posting which possibilities I see: 1. Install the package such that it works without workarounds (at least optionally), no matter whether it matches some ideals in a nonexisting world. 2. Make clear by package name and README that you install a fork disagreeing with upstream. 3. Remove the package. Obviously, my preference of choice is 1, then 2, and 3 the least. A technical note, you might not be aware of: Already since quite a while new option passing requested by users in sys-block/zram-init could not reasonably be implemented without push, i.e. all recent versions of that package need push if that feature is used by users. This usage has nothing to do with our discussion: It would not be my style to introduce an artificial dependency to support my arguments - it simply was the only natural way to implement said feature, because this is exactly what I have written push for. And a personal note: Just a few days ago, I had another case where I was hesitating to use my own project, because of this gentoo incompatible installation. When this happens, something is fundamentally wrong IMHO. That's why I see the above mentioned points as the only viable alternatives.
(In reply to Martin Väth from comment #5) > Implicitly, also users are forced to mount /usr/share noexec (or even more > specific workarounds are required for testing availability) because of the > poor choice of the path, but I consider this point already nonessential. you mean option "exec", the execute bit has been removed from the shell scripts, too. > > I made clear in my first posting which possibilities I see: > > 1. Install the package such that it works without workarounds (at least > optionally), no matter whether it matches some ideals in a nonexisting world. USE="-vanilla" > 2. Make clear by package name and README that you install a fork disagreeing > with upstream. if ! use vanilla ; then elog "... has been installed into /usr/share/${PN}" ; fi > 3. Remove the package. This is a no-go, imho.
(In reply to Michael Weber from comment #6) > USE="-vanilla" Triggering of QA violations is not the purpose of use flags.
