Several users have mistakenly selected the experimental 17.1 profile. It would be helpful if eselect profile would output the profile status to make it clear that dev/exp profiles are not intended for general use.
Created attachment 513764 [details, diff] Patch for profile module Please test attached patch. Is the output format o.k. like this?
Example output: Available profile symlink targets: [1] default/linux/amd64/13.0 (stable) [2] default/linux/amd64/13.0/selinux (dev) [3] default/linux/amd64/13.0/desktop (stable) [4] default/linux/amd64/13.0/desktop/gnome (stable) [5] default/linux/amd64/13.0/desktop/gnome/systemd (stable) [6] default/linux/amd64/13.0/desktop/plasma (stable) [7] default/linux/amd64/13.0/desktop/plasma/systemd (stable) [8] default/linux/amd64/13.0/developer (stable) [9] default/linux/amd64/13.0/no-multilib (dev) [10] default/linux/amd64/13.0/systemd (stable) [11] default/linux/amd64/13.0/x32 (dev) [12] default/linux/amd64/17.0 (stable) [13] default/linux/amd64/17.0/selinux (dev) [14] default/linux/amd64/17.0/hardened (dev) [15] default/linux/amd64/17.0/hardened/selinux (dev) [16] default/linux/amd64/17.0/desktop (stable) [17] default/linux/amd64/17.0/desktop/gnome (stable) [18] default/linux/amd64/17.0/desktop/gnome/systemd (stable) [19] default/linux/amd64/17.0/desktop/plasma (stable) [20] default/linux/amd64/17.0/desktop/plasma/systemd (stable) [21] default/linux/amd64/17.0/developer (stable) [22] default/linux/amd64/17.0/no-multilib (dev) [23] default/linux/amd64/17.0/no-multilib/hardened (dev) [24] default/linux/amd64/17.0/no-multilib/hardened/selinux (dev) [25] default/linux/amd64/17.0/systemd (stable) [26] default/linux/amd64/17.0/x32 (dev) [27] hardened/linux/amd64 (stable) [28] hardened/linux/amd64/selinux (stable) [29] hardened/linux/amd64/no-multilib (stable) [30] hardened/linux/amd64/no-multilib/selinux (stable) [31] hardened/linux/amd64/x32 (dev) [32] default/linux/musl/amd64 (exp) [33] hardened/linux/musl/amd64 (exp) [34] default/linux/musl/amd64/x32 (exp) [35] hardened/linux/musl/amd64/x32 (exp) [36] default/linux/uclibc/amd64 (dev) [37] hardened/linux/uclibc/amd64 (dev)
The output looks ok to me. Maybe we could add a warning at the top of bottom to select a stable profile. Something like: Please select a profile marked (stable) unless you know what you are doing.
In an ideal world, I'd love to see this output colorized so the stable profiles are green and dev/exp are yellow or red. Not sure how easy that'd be to implement. What's shown in comment 2 is already a big improvement though.
Created attachment 513776 [details, diff] Patch v2 for profile module (In reply to Mike Gilbert from comment #3) > Maybe we could add a warning at the top of bottom to select a stable > profile. Something like: > > Please select a profile marked (stable) unless you know what you are doing. Not sure if the list output would be the right place to add such an explanation. There are also arches that don't have a stable profile at all. (In reply to Ben Kohler from comment #4) > In an ideal world, I'd love to see this output colorized so the stable > profiles are green and dev/exp are yellow or red. Not sure how easy that'd > be to implement. Sorry, but eselect's highlight functions currently support only two colours, namely blue and red. :) Updated patch is attached, red for dev/exp and blue otherwise.
(In reply to Ulrich Müller from comment #5) > Sorry, but eselect's highlight functions currently support only two colours, > namely blue and red. :) Updated patch is attached, red for dev/exp and blue > otherwise. Thinking about it, this additional highlighting will make the * marker for the selected profile stand out less. So maybe it's not such a good idea.
I think the first patch you posted would be a reasonable first step.
Yeah I'd agree. I like the idea of colorization but with the current limitations I think that the colorized output is less readable/useful than the plain output of your first patch.
https://gitweb.gentoo.org/proj/eselect.git/commit/?id=a25b292e4feaab4b3c073eeb1ed96166893e2d2b Please test with eselect-9999.
Created attachment 513844 [details, diff] Require --force to select an experimental profile Another idea, "eselect profile set" could refuse selecting an experimental profile, with the possibility to override it with the --force option. Patch to be applied on top of commit a25b292e4feaab4b3c073eeb1ed96166893e2d2b.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=fd6bc0a8f5fa550a26afc480361bd95aac3481d0 commit fd6bc0a8f5fa550a26afc480361bd95aac3481d0 Author: Ulrich Müller <ulm@gentoo.org> AuthorDate: 2018-01-09 08:55:44 +0000 Commit: Ulrich Müller <ulm@gentoo.org> CommitDate: 2018-01-09 09:05:53 +0000 app-admin/eselect: Version bump. Bug: https://bugs.gentoo.org/643864 Package-Manager: Portage-2.3.19, Repoman-2.3.6 app-admin/eselect/Manifest | 1 + app-admin/eselect/eselect-1.4.11.ebuild | 61 +++++++++++++++++++++++++++++++++ 2 files changed, 62 insertions(+)}
I have released eselect-1.4.11. Please test.
@Prefix: Adding you to CC. It's a bit late in the game, but given that all prefix profiles are experimental, is the change mentioned in comment 10 acceptable for you? This is already released as eselect-1.4.11.
I agree with this change. And thanks for reminding us to push Prefix profiles from exp into dev.
Just as info to get a complete picture here: This is the profiles.desc that Prefix users get: https://rsync.prefix.bitzolder.nl/profiles/profiles.desc Prefix users currently get dev-status profiles, so the eselect change won't affect them. This is not the case for RAP users, because they use the gentoo-x86 tree. I'm with Benda that we should probably see to getting (at least) the linux/RAP profiles in dev status now.
Thanks. So, from the last two comments I conclude that I can resolve this as FIXED, and that we can proceed with early stabilisation of eselect-1.4.11 as planned.
