Re: [gentoo-dev] Unmasking modular X

[Donnie Berkholz]

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