The proposal was originally for alternatives, but now the change page lists conflicting packages as the alternative approach. If we're to vote on something, we'd need to know what the decision is.

The proposal was originally for alternatives, but now the change page lists conflicting packages as the alternative approach. If we're to vote on something, we'd need to know what the decision is.

Current approach is to have main package to produce -bin packages for node, npm, npx. Right now we are figuring out dependencies between those, and conflicts.

OK. So please update the Change page on the wiki.

OK. So please update the Change page on the wiki.

Updated, does it look sane now?

OK. So please update the Change page on the wiki.

Updated, does it look sane now?

Looks better, though you still need to update the user experience. I think it needs more detail on how the -bin packages will work too. For example: what will happen on upgrades to new Fedora releases if the version currently providing /usr/bin/node is not available on the next release?

Looks better, though you still need to update the user experience. I think it needs more detail on how the -bin packages will work too. For example: what will happen on upgrades to new Fedora releases if the version currently providing /usr/bin/node is not available on the next release?

Good question! I think it depends on what generally happens with installed packages that are dead in the new releases. If they stay on the system, they stay on the system (and /usr/bin/node will be kept pointing to the EOL release). If we can make sure we obsolete that somehow (add to fedora-obsolete-packages?), they should be uninstalled with the rest of the stream and disappear; unless the user happens to install a new stream in the same transaction, in which case they should be just replaced with the -bin packages of the new stream (since the old ones are now out of the way and the new ones can be pulled in as weak dependency). I have no idea ATM if we can convince dnf to act differently.

My current thoughts on the matter:

• People were afraid that the update-alternatives have a bunch of corner cases; I feel like we are discovering all/some of the corner cases again, but on the rpm/dnf level instead of on the system level.

• We have some rudimentary test scenarios and testing COPR with PoC; I'll add the links to the proposal as well. If you can think of any other scenarios you are afraid migh get us, please let us know, we'll try to cover it as well.

• We are learning a bunch of things about rpm, dnf, and/or libsolv as we go along trying to address those issues while running into new ones as we go along. If you happen to know any tools or hidden features that would be useful in implementation, let us know.

• Given the approaching implementation deadline, I'm half expecting we'll have to postpone the implementation to F44 anyway. If you feel that the proposal in the current state is not good enough, feel free to vote against, although in that case I would be very glad if you can make a distinction of "not a good idea at all" vs. "underbaked, but keep trying and we'll see how it will look in time for F44".

I have updated the user-experience section with the log output of the current state from the testing COPR; this is pretty close to how we think the interaction with this system should look like. I'll do an update in the discussion thread and leave this ticket primarily for voting.

as per the request of the change owner, this proposal has now been retargeted to F44 and this is updated in the change wiki. I will add a tracker bug if this change is approved.

+1

For the record, I'm +1 on this for F44.

Accepted: (+2, 0, -0) after two weeks.

FYI the page was still listed in the ChangeAcceptedF43 category on the Wiki, which made it show up in the F43 changeset, so I fixed that.

Thanks @pbokoc !