Ciaran McCreesh wrote: > * There is a clean upgrade solution available that will result in > non-ported packages merely pulling in a load of extra unnecessary > packages (that non-modular users have anyway). > > * The clean solution visibly illustrates that a package is unported. > Users who are running ~arch can clearly see this, and can file bugs and > (if they care) attempt a --nodeps installation. The bugs can be picked > up by the package maintainers or the volunteers on this list.
Yes, for all 3 people who have a clue what it means when virtual/x11 gets pulled in. How many users do you seriously think will have a clue and think "Oh, virtual/x11 is getting pulled in here. I must have a package that isn't ported to modular X somewhere in this list. Let me track it down and file a bug."? > * The clean solution is the solution originally proposed to this list, > and the reason we are using new style virtuals. No, this is wrong. The reason we are using new style virtuals is so we could have a versioning in what provides virtual/x11. Namely, 6.8 or older. > * There is an alternate upgrade solution that means that any users who > have an unported package will get their screen filled with several > pages of incomprehensible bright red crap. Several pages? How is that coming from a single unported package? Also, it's not incomprehensible and shouldn't be to anyone on ~arch (or frankly, anywhere), because packages involving blockers regularly have to be dealt with. > * There are currently enough unported packages that many ~arch users > will probably have one or two installed (assumption: many users have > several utterly random non-mainstream packages installed). Possible, but we can't prove this one way or the other. Certainly very few modular X users have encountered apps that are still unported, as evidenced by very few remaining blockers on #112675. And there are a fairly large number of > * Despite your original assurances to this list, you intend to go ahead > and take the alternate solution, which will lead to one of the most > user visible and hardest to fix breakages we've ever had. Yes, I suggested handling this differently back in early August, when these things were in the planning stage. But even later that month, I posted saying that wasn't the best way to handle it. It's not difficult to imagine that things can change over the course of 6 months. > * You are doing this because you believe that it is better to get every > package ported over extremely quickly rather than having the odd > package with extra unnecessary listed dependencies, and you do not > consider the impact upon our users to be relevant. I consider ~arch users to have agreed to help test and fix new things. This is included. I would not do the same thing to our stable tree, or if we only had a stable tree. Yes, I do think it is better to have a quick solution and let some of our ~arch users see a couple of blocks, for which they will file bugs. Then these bugs will be fixed within a day, and those users will again have working systems. I don't see what the big deal is. By being ~arch users, they're already asking to use ebuilds that have a chance of breaking their systems permanently, let alone a single 'emerge sync'. Thanks, Donnie
signature.asc
Description: OpenPGP digital signature
