Following Gentoo's documentation, users will prefer emergeing plasma-meta rather than emergeing each one of the individual packages. However, because of the >= version specifier chosen to specify the dependencies (>=kde-plasma/whatever-${PV}:${SLOT}) in a PV=X ebuild, any user willing to downgrade from PV=X+ will have to find and mask each one of the individual packages in its X+ version. Is'nt it a typical use case for the ~ version specifier ? Would'nt a ~kde-plasma/whatever-${PV}:${SLOT} specification in a PV=X ebuild enable the user to downgrade whatever & friends from their X+1 version by only masking plasma-meta in its X+ version without preventing individual revision upgrades ? I believe so. Reproducible: Always
Plasma meta must ensure minimum PV otherwise it does not fulfill its purpose. ~ specifier will not let you downgrade to <PV either, instead it is even more restrictive than what we have now - upstream will from time to time make 5.xx.x.1 point releases which ~ would not allow upgrading to. Revisions are not problematic to downgrade at all right now. Tell me if I have missed anything else from your proposal.
kde overlay provides package.mask files for users wanting to lock Plasma or Frameworks or Gear to a lower version...
(In reply to Andreas Sturmlechner from comment #1) > ~ specifier will not let you downgrade to <PV either, If < PV meta package's dependencies are specified like this, I would expect masking meta package PV sufficient for downgrading all PV dependencies since they would no longer satisfy < PV requirements. Anyway, > upstream will from time to time make 5.xx.x.1 point releases I did not know that and acknowledge that this indeed ruins the efficiency of the solution I had suggested. However the need remains, particularly when wishing to downgrade from tildarched meta. (In reply to Andreas Sturmlechner from comment #2) > kde overlay provides package.mask files I was used to resort to the package list provided as part of stabilization bugs with the inconvenience that the list is… not available prior to the stabilization request. ;-) So thank you for the tip, I'll check next time. Not that handy for the common gentooer though.
(In reply to Eric F. GARIOUD from comment #3) > Not that handy for the common gentooer though. I would say it is not a common request.[1] Much more common is the reverse case which we are covering for. [1] and then a quick inquiry into medium level portage mastery in f.g.o or irc will quickly yield a command like `qlist -CI kde-plasma/*` for everyone to easily assemble their own masking list.
(In reply to Andreas Sturmlechner from comment #4) > I would say it is not a common request. For sure ! I can't remember having already asked for this. ;-) But I can't remember either having upgraded KF & plasma-meta >=whatever.4 and facing so many troubles that I feel compulsory to downgrade the whole lot. Particularly after having tested a not that much problematic ~plasma-meta < 4 + previous KF stable. Was the choice of stabilizing kde-plasma 5.23.4 + KF88 more hazardous than stabilizing 5.23.3 (on existing KF85 stable) (I read in associated bugs that there has been some (justified) hesitation). I won't & cannot judge and this is another story. BTW, this was just an enhancement request about a facility I thought just easy to achieve. You demonstrated it is actually not. Additionally your help tracking kwin, kcoreaddons and plasma bugfixes (BUG #829335) is indeed more appreciated than fiddling meta ebuilds for (one?)user's convenience. Therefore feel free to close this request WONTFIX.
(In reply to Eric F. GARIOUD from comment #5) > Was the choice of stabilizing kde-plasma 5.23.4 + KF88 more hazardous than > stabilizing 5.23.3 (on existing KF85 stable) (I read in associated bugs that > there has been some (justified) hesitation). I won't & cannot judge and this > is another story. 5.23 requires >=KF-5.86 so anything else was not an option. I did not see any such hesitation as you describe. All in all this was a successful stabilisation, going for .4 always implies watching out for upcoming bugs.
