Long story short: 1. wine team has released a news item about new wine packaging *in April*, 2. the packages were masked until a few days ago when they were silently unmasked, 3. the app-emulation/wine package became unmaintained with no clean way of indicating the necessity of upgrade. So now we've reached a point when most of Gentoo users have heard of new wine packaging back in April but didn't do anything about it because it was masked for 5 more months. They have no clue that they're supposed to do the action now because they have no clue that the packages are finally unmasked, and the wine team does not care to provide a clear migration path. I think we can do *much better* than releasing a news item and expecting people to regularly recheck if it finally applies for 5+ months.
Does updating the news item with an explicit emerge command satisfy your needs for "clean way of indicating the necessity of upgrade?"
This won't change the fact that people who read the news item 5 months ago have no way of knowing that it finally started to apply today. But out of curiosity, please provide the suggested emerge command because I'm pretty sure it won't work.
(In reply to Michał Górny from comment #2) > This won't change the fact that people who read the news item 5 months ago > have no way of knowing that it finally started to apply today. > > But out of curiosity, please provide the suggested emerge command because > I'm pretty sure it won't work. So what are you proposing?
I have already expressed my suggestion -- turn app-emu/wine into meta-ebuild pulling the new stuff in.
(In reply to Michał Górny from comment #4) > I have already expressed my suggestion -- turn app-emu/wine into meta-ebuild > pulling the new stuff in. Aaaand, that'll be confusing as all hell to users, as I already told you.
(In reply to NP-Hardass from comment #5) > (In reply to Michał Górny from comment #4) > > I have already expressed my suggestion -- turn app-emu/wine into meta-ebuild > > pulling the new stuff in. > > Aaaand, that'll be confusing as all hell to users, as I already told you. ...because? FYI, last time we talked you actually agreed with me. Then you suddenly changed your mind and unmasked something completely different without even bothering to tell me.
(In reply to Michał Górny from comment #6) > (In reply to NP-Hardass from comment #5) > > (In reply to Michał Górny from comment #4) > > > I have already expressed my suggestion -- turn app-emu/wine into meta-ebuild > > > pulling the new stuff in. > > > > Aaaand, that'll be confusing as all hell to users, as I already told you. > > ...because? FYI, last time we talked you actually agreed with me. Then you > suddenly changed your mind and unmasked something completely different > without even bothering to tell me. Because, users, without warning, will have packages pulled in without choosing or even knowing about the packaging change, which will be confusing. "I have wine installed, why is it trying to install wine?" Because it's a big change, and users should knowingly enter the change, as opposed to it happening without their knowledge. Because, from my discussions with users, there isn't much non-global/profile USE flag setting on wine, so using a package to apply all of the flags from one meta on all of them is overkill, and in fact would prevent many users that I spoke to from using the flags on different versions the way that they'd like to. Moreover, it complicates things where packages are forced to have the same USE flags even though there is no logical reason for that to be the case. Not forcing this removes the entire purpose of mirroring the USE flags from the original packaging. Without mirroring the USE flags, having app-emulation/wine become a meta would be even more confusing because all the USE flags would be dropped to what we have for virtual/wine now. Resolving those issues in a (somewhat) satisfactory way resulting in an ebuild which you told me was "incorrect." Because, users had already received instruction that things would be done in a certain way and without warning, we'd be completely changing it. Doing it that way would also mean that the package would have to be auto-committed to stable, would result in effectively dropping a package without a mask, and a variety of other unnecessary things related to package management. When we spoke (with your QA hat off), I told you it was an interesting idea, and I would consider it. Afterward, I spoke to my project members at length about it, and the current solution (which is what we had) is what we decided to go forward with. There was nothing sudden about it. We had quite an in depth discussion, several times, within the project. I felt no need to confer with you after making the decision because speaking to my team about it was the only thing that seemed necessary (particularly because you spoke to me about it as a suggestion, not with your QA hat).
This seems relatively easy to fix: Whilst it's unfortunate that there is a long period between the news item from april and the actual roll-out that's currently a given, we can't change it anymore. We can learn from it that this should probably be done differently next time a change is introduced/announced (not wine specific) I don't think the unmasking is really a problem, since only new packages were unmasked. Current users of app-emulation/wine won't see any change. The only thing missing seems to be a (new) news announcement that app-emulation/wine will be masked within some period and that people should switch to one of the other options. This should of course only be posted when the actual masking is planned. The only question I have is when this switch/masking would happen and what still needs to be done to make it happen. For example: Is there still some QA work needed on the the new wine packages and eselect-wine?
Not a fan of how it was handled back then (and state of eselect-wine), but 5 years later it's a bit late to do anything here.
