Is it normal, to stabilize packages like that: https://gitweb.gentoo.org/repo/gentoo.git/commit/app-emulation/winetricks?id=7044ead05a2478726d1ccfdc188bac8bf1545578 ?
Looks like an accident to me.
Long time ago, I had a discussion with arch teams about self stabilization for wine itself since it is a big package and its easier for us to do all of the testing since we are familiar with it. As such, we made it project policy to self stabilize our packages when we feel it appropriate so long as we thoroughly test it (as that is the condition that arch teams originally set when it was discussed with them) In addition, x86 and amd64 have long maintained that maintainers can self stabilize so long as they test thoroughly, unless things have changed.
I wouldn't say the self-stabilization is as much the problem as committing a version bump of ~arch package straight to stable.
(In reply to Michał Górny from comment #3) > I wouldn't say the self-stabilization is as much the problem as committing a > version bump of ~arch package straight to stable. FYI, I'm the upstream for this particular package. I had discussed with NP-Hardass a while back about stabilizing winetricks. It can change somewhat rapidly (or not all), as new features are added and as URLs change. There's no reason to ever run an old version, latest is always greatest here. As the maintainer in Gentoo and upstream, I feel that it is stable, and did so. I didn't see any value gained by committing as ~arch, then later stabilizing. If there's some reason to do that extra step, I'd like to know. I just used the version bump opportunity to also start stabilizing winetricks releases.
should winetricks depend only on virtual/wine?
(In reply to Fabio Rossi from comment #5) > should winetricks depend only on virtual/wine? @NP-Hardass? For me, that's fine. It doesn't need a particular wine version (and can use a non-portage installed version as well, for that matter, as long as it's in path or set via WINE=/path/to/wine).
(In reply to Austin English from comment #6) > (In reply to Fabio Rossi from comment #5) > > should winetricks depend only on virtual/wine? > > @NP-Hardass? > > For me, that's fine. It doesn't need a particular wine version (and can use > a non-portage installed version as well, for that matter, as long as it's in > path or set via WINE=/path/to/wine). Not really the appropriate place for this discussion (since it is a bug about winetricks stabilization QA)... but that's OK... Yes, eventually, winetricks can depend only on virtual/wine. Should it only depend on that now? I don't think so... app-emulation/wine is still in the tree (masked for removal). The real issue here is precedence of dependencies within Portage dependency calculations. It'd probably be wise to edit all ebuilds from || ( app-emulation/wine virtual/wine ) to || ( virtual/wine app-emulation/wine ) now that app-emulation/wine is masked for removal. That'll resolve the issue being raised with this inquiry. Personally, I'd rather keep the || () block just in case someone else is using older packages (at a minimum for several months, maybe longer)... there isn't much reason to drop support, but I defer to the maintainer of that package on that decision.
