$ eselect wine set 1 * ACCESS DENIED: unlinkat: /usr/bin/function_grep.pl rm: cannot remove '/usr/bin/function_grep.pl': Permission denied !!! Error: Failed to rm /usr/bin/function_grep.pl Call stack: * remove_symlinks (wine.eselect:744) * do_unset (wine.eselect:495) * do_set (wine.eselect:556) * check_do (core.bash:24) * do_action (core.bash:105) * main (eselect:181) exiting --- /usr (with minor necessary exceptions) is reserved for the package manager to mangle. eselect modules should limit themselves to /etc and /var. (And a lot of horrible eselect modules out there is no excuse to add more)
Do you have any suggestions on how to remediate the situation?
Alter PATH instead of creating symlinks in /usr/bin.
(In reply to Michał Górny from comment #2) > Alter PATH instead of creating symlinks in /usr/bin. That'll work for the traditional symlinks, but not the ones for /usr/bin/wine-staging, /usr/bin/winecfg-staging for example.
You can create the additional symlinks in the package-specific bindir.
(In reply to Michał Górny from comment #4) > You can create the additional symlinks in the package-specific bindir. I am not sure what you mean by package-specific bindir.
The directory you'll be adding to PATH, e.g. /usr/lib/wine-any-2.17/bin
(In reply to Michał Górny from comment #6) > The directory you'll be adding to PATH, e.g. /usr/lib/wine-any-2.17/bin OK, so... if I have wine-vanilla:2.17 set as default for wine, i'd add PATH to /usr/lib/wine-vanilla-2.17/bin to PATH. when I want to use wine-any:2.17 for wine-staging, I do what? I can't put the symlinks in /usr/lib/wine-any-2.17/bin, as that'll override wine... Unless you are suggestion at buildtime creating a folder of symlinks /usr/lib/wine-any-2.17/bin-staging. That sounds really messy.
Are you saying that the eselect symlinks random *wrong* variants of wine into other variants? Then that's insanely confusing and should be gone.
(In reply to Michał Górny from comment #8) > Are you saying that the eselect symlinks random *wrong* variants of wine > into other variants? Then that's insanely confusing and should be gone. No, the symlinks are for featuresets... all ebuilds that provide the wine-staging patchset are candidates for the wine-staging symlink, all that provide gallium nine are candiates for the wine-d3d9 symlink, and all wine ebuilds are candidates for the wine symlink.
That's just insane completion spam but whatever. Just force a specific preference and be done with it. There's no sane reason to combine staging from any and d3d9 from d3d9 if any has it too.
(In reply to Michał Górny from comment #10) > That's just insane completion spam but whatever. > > Just force a specific preference and be done with it. There's no sane reason > to combine staging from any and d3d9 from d3d9 if any has it too. You seem to be missing the point here... Applications with wine work for some version or some patchset, but not others. It's entirely up to the user to choose what they want/need. if they have wine-any with staging and d3d9 and prefer to use that with some app, they can, if they prefer/need to use one with just staging, just d3d9, or vanilla, that's all their choice, based on what works for them. It goes against the point of providing options by ignoring them and forcing something on the user against their wishes.
It goes against the point of having sanity to have 5 different symlinks pointing to the same program, or maybe different based on what someone accidentally eselects or installs, or removes, and some other convoluted rules. Some say Gentoo is about choice. Some turn that choice into insanity which is no longer a valid option but an effort for the sake of itself and nowhere close to providing a viable option. If I install both wine-staging and wine-any for some reason, I *do not* expect wine-staging symlink to actually mean wine-any just because some fancy semi-random logic based on merge order decided that for me.
(In reply to Michał Górny from comment #12) > It goes against the point of having sanity to have 5 different symlinks > pointing to the same program, or maybe different based on what someone > accidentally eselects or installs, or removes, and some other convoluted > rules. > > Some say Gentoo is about choice. Some turn that choice into insanity which > is no longer a valid option but an effort for the sake of itself and nowhere > close to providing a viable option. > > If I install both wine-staging and wine-any for some reason, I *do not* > expect wine-staging symlink to actually mean wine-any just because some > fancy semi-random logic based on merge order decided that for me. Semi random logic based on merge order? What on earth are you talking about? There is no randomness at all. The wine-staging symlink is any slot of app-emulation/wine-staging or app-emulation/wine-any[staging]. That is because, once you apply the wine-staging patchset, you have built wine-staging. The user chooses to set that symlink, it is only automatically set if the user doesn't have any satisfying ebuild installed. This bug is about writing in /usr. Please keep it on topic. Moreover, if this is an issue with other eselect modules, and we want to make an effort to fix them, please file a tracker bug and file bugs for every other offending package so it doesn't feel this is a crusade against the wine packaging because you don't like it (because that is how it is coming across)
(In reply to NP-Hardass from comment #13) > (In reply to Michał Górny from comment #12) > > It goes against the point of having sanity to have 5 different symlinks > > pointing to the same program, or maybe different based on what someone > > accidentally eselects or installs, or removes, and some other convoluted > > rules. > > > > Some say Gentoo is about choice. Some turn that choice into insanity which > > is no longer a valid option but an effort for the sake of itself and nowhere > > close to providing a viable option. > > > > If I install both wine-staging and wine-any for some reason, I *do not* > > expect wine-staging symlink to actually mean wine-any just because some > > fancy semi-random logic based on merge order decided that for me. > > Semi random logic based on merge order? What on earth are you talking about? > There is no randomness at all. The wine-staging symlink is any slot of > app-emulation/wine-staging or app-emulation/wine-any[staging]. That is > because, once you apply the wine-staging patchset, you have built > wine-staging. The user chooses to set that symlink, it is only > automatically set if the user doesn't have any satisfying ebuild installed. So if I have no wine version installed, and I do 'emerge -1v wine-staging wine-any' (with staging patchset), which version will be run via wine-staging?
(In reply to Michał Górny from comment #14) > (In reply to NP-Hardass from comment #13) > > (In reply to Michał Górny from comment #12) > > > It goes against the point of having sanity to have 5 different symlinks > > > pointing to the same program, or maybe different based on what someone > > > accidentally eselects or installs, or removes, and some other convoluted > > > rules. > > > > > > Some say Gentoo is about choice. Some turn that choice into insanity which > > > is no longer a valid option but an effort for the sake of itself and nowhere > > > close to providing a viable option. > > > > > > If I install both wine-staging and wine-any for some reason, I *do not* > > > expect wine-staging symlink to actually mean wine-any just because some > > > fancy semi-random logic based on merge order decided that for me. > > > > Semi random logic based on merge order? What on earth are you talking about? > > There is no randomness at all. The wine-staging symlink is any slot of > > app-emulation/wine-staging or app-emulation/wine-any[staging]. That is > > because, once you apply the wine-staging patchset, you have built > > wine-staging. The user chooses to set that symlink, it is only > > automatically set if the user doesn't have any satisfying ebuild installed. > > So if I have no wine version installed, and I do 'emerge -1v wine-staging > wine-any' (with staging patchset), which version will be run via > wine-staging? it'll set the symlink when you emerge the first one. You set it to whatever you want after that By that logic, if I emerge wine-vanilla:2.10 wine-vanilla:2.11, I'll have the symlink set to 2.10 even though a newer version is available. But I can change it as I see fit. The version set by symlink is entirely up to the user. It's not magically forced to be anything. The purpose of setting it is so they can make the default whatever they need it to be, since wine versions or patchsets may not work with their desired application.
(In reply to NP-Hardass from comment #15) > (In reply to Michał Górny from comment #14) > > (In reply to NP-Hardass from comment #13) > > > (In reply to Michał Górny from comment #12) > > > > It goes against the point of having sanity to have 5 different symlinks > > > > pointing to the same program, or maybe different based on what someone > > > > accidentally eselects or installs, or removes, and some other convoluted > > > > rules. > > > > > > > > Some say Gentoo is about choice. Some turn that choice into insanity which > > > > is no longer a valid option but an effort for the sake of itself and nowhere > > > > close to providing a viable option. > > > > > > > > If I install both wine-staging and wine-any for some reason, I *do not* > > > > expect wine-staging symlink to actually mean wine-any just because some > > > > fancy semi-random logic based on merge order decided that for me. > > > > > > Semi random logic based on merge order? What on earth are you talking about? > > > There is no randomness at all. The wine-staging symlink is any slot of > > > app-emulation/wine-staging or app-emulation/wine-any[staging]. That is > > > because, once you apply the wine-staging patchset, you have built > > > wine-staging. The user chooses to set that symlink, it is only > > > automatically set if the user doesn't have any satisfying ebuild installed. > > > > So if I have no wine version installed, and I do 'emerge -1v wine-staging > > wine-any' (with staging patchset), which version will be run via > > wine-staging? > > it'll set the symlink when you emerge the first one. You set it to whatever > you want after that > > By that logic, if I emerge wine-vanilla:2.10 wine-vanilla:2.11, I'll have > the symlink set to 2.10 even though a newer version is available. But I can > change it as I see fit. The version set by symlink is entirely up to the > user. It's not magically forced to be anything. The purpose of setting it > is so they can make the default whatever they need it to be, since wine > versions or patchsets may not work with their desired application. I should stress, this is how ALL eselect modules work. They initially set the symlink when a target is available (or they set nothing by default). Whether we are setting it or not by default is a function of the ebuild, not the eselect module
No, this is *not* how all eselect modules work. 1. They don't usually make 'foo-staging' mean 'foo-any' when 'foo-staging' is an explicit choice. 2. They usually automatically upgrade (except for really fragile stuff) on upgrade if the user did not specifically select another option. I guess you can ignore 2 and leave it for depclean to handle. However, I disagree that making 'wine-staging' not mean 'wine-staging' when that is *explicitly installed* is correct.
(In reply to Michał Górny from comment #17) > No, this is *not* how all eselect modules work. > > 1. They don't usually make 'foo-staging' mean 'foo-any' when 'foo-staging' > is an explicit choice. > > 2. They usually automatically upgrade (except for really fragile stuff) on > upgrade if the user did not specifically select another option. > > I guess you can ignore 2 and leave it for depclean to handle. However, I > disagree that making 'wine-staging' not mean 'wine-staging' when that is > *explicitly installed* is correct. Again, not the point of this bug, and off topic. Your logic doesn't work when not even considering which packages are candidates for which symlinks. Just dealing with versions/slots alone breaks in your suggestion. If the user wants the wine symlink to be wine-staging 2.1 and the wine-staging symlink to be wine-staging 2.2, by having symlinks in the same dir as the bin prefix, this simply won't work. Let's get back to discussing possible solutions rather than debating the semantics of which packages are considered as candidates for which symlinks.
Then install a lot of directories with lot of symlinks and be happy with providing user a lot of completely useless choice for the sake of it.
(In reply to Michał Górny from comment #19) > Then install a lot of directories with lot of symlinks and be happy with > providing user a lot of completely useless choice for the sake of it. So, you have no other suggestions that avoid needless buildtime symlink creation?
Nope, that's the reference solution to the problem you're creating.
fwiw current impl I'm experimenting with doesn't touch anything but /etc/eselect/wine (albeit still early stages, so unsure how that will end up)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=1954598a4b9fee10c063f6be17d07b47e7e93e4b commit 1954598a4b9fee10c063f6be17d07b47e7e93e4b Author: Ionen Wolkens <ionen@gentoo.org> AuthorDate: 2022-11-16 03:30:33 +0000 Commit: Ionen Wolkens <ionen@gentoo.org> CommitDate: 2022-11-16 15:01:04 +0000 app-eselect/eselect-wine: add 2.0.0, unkeyworded for testing Complete rewrite but for notable bits: - removes register/deregister, can auto-update without this - no longer touch files in /usr at runtime wrt bug #632576, in this case it was particularly invasive doing *many* modifications to /usr/bin and /usr/share/man - handle /usr/lib/wine fwiw wrt bug #657748 (installed by the ebuild), albeit winebuild can find the right path nowadays - fix prefix wrt bug #717470 - give feedback when switching wrt bug #874612 - tries harder to not unexpectedly switch variant/version, and no longer need ebuild checks wrt bug #881035 - no longer hardcodes variants and so can support any random ones, i.e. an overlay can do wine-tkg or wine-myfunnyfork - --all, --vanilla, etc.. options were removed, but can still perform similar actions (see `help`) - `list` can now show selections for all variants at once - `unset` removed, not seeing a motivation (esp if not polluting /usr) - half+ the original size, and switches variant noticeably faster Still experimental and subject to changes, so unkeyworded for now. See README.rst for more notes, or the tarball's impl.rst for details. ebuild itself needs some nonsense largely caused by being difficult to get rid of the old eselect plus portage limitations. Bug: https://bugs.gentoo.org/632576 Bug: https://bugs.gentoo.org/657748 Bug: https://bugs.gentoo.org/717470 Bug: https://bugs.gentoo.org/874612 Bug: https://bugs.gentoo.org/881035 Signed-off-by: Ionen Wolkens <ionen@gentoo.org> app-eselect/eselect-wine/Manifest | 1 + app-eselect/eselect-wine/eselect-wine-2.0.0.ebuild | 88 ++++++++++++++++++++++ 2 files changed, 89 insertions(+)
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=5bf131a2a1d9365fcf992468091ce2814782dc3e commit 5bf131a2a1d9365fcf992468091ce2814782dc3e Author: Ionen Wolkens <ionen@gentoo.org> AuthorDate: 2022-11-23 16:10:41 +0000 Commit: Ionen Wolkens <ionen@gentoo.org> CommitDate: 2022-11-23 20:38:21 +0000 app-eselect/eselect-wine: unleash eselect-wine-2 Had expected to need a 2.0.1 before this, but no issues reported so far. Let's see how it goes. I do imagine it may cause some confusion given portage doesn't make emerging it pretty and need to source /etc/profile at least once, but have no "good" solutions to these beside warnings. (also expecting a benign tinderbox bug about symlinks which can't be silenced currently) Closes: https://bugs.gentoo.org/632576 Closes: https://bugs.gentoo.org/657748 Closes: https://bugs.gentoo.org/717470 Closes: https://bugs.gentoo.org/874612 Signed-off-by: Ionen Wolkens <ionen@gentoo.org> app-eselect/eselect-wine/eselect-wine-2.0.0.ebuild | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
Why can't we create symlinks in /usr/bin once that point to /etc/eselect/wine/bin/*, say, in app-eselect/eselect-wine ebuild?
Formerly had a /usr/bin/wine symlink for compat but that it wasn't the "complete" set confused some things like lutris. And complete set is more annoying given we don't know what's available (there could be no wine64, no perl scripts, etc... depending on USE of each variants), and we'd have to install broken symlinks. Ultimately it's all in PATH similarly to clang anyhow.
