#2356 Fedora 31: Reset eclipse stream for all (once) or leave the bugzilla unfixed?
Closed: Accepted a year ago by zbyszek. Opened a year ago by churchyard.

This is a request for a FESCo resolution of https://bugzilla.redhat.com/show_bug.cgi?id=1780827

What happened

During the Fedora 31 stable time line (after GA, before EOL) for a short period of time in December 2019, the eclipse module gained a default stream. Users of Fedora 31 who have run dnf upgrade (or dnf update) and happened to have packages also part of the eclipse module (but not eclipse-only-related) installed, were migrated to the content provided by the eclipse module. The eclipse module was enabled, as well as dependencies ant and maven. As an example, this has manifested by replacing the non-modular protobuf package with the modular protobuf package (built with disabled features) (without the users doing anything else than dnf upgrade).

The default eclipse stream was removed without further ado. A bugzilla was opened to migrate all affected users back, because subsequent dnf upgrade won't help. That bugzilla has not been fixed since despite it being approved as prioritized bug couple days after opening it.

Proposed fix

There is a fix proposed that adds a scriptlet to fedora-release-common that resets the eclipse module on next dnf upgrade. The scriptlet is written to only do it once per the system existence. Users that intentionally enabled eclipse will most likely get a broken setup because of unrelated bug of the maven module. Hence this fix is potentially disturbing to some of our users (unknown number).

The fix does not reset maven and ant because that makes no practical difference.

OTOH The problem is disturbing to an unknown number of users as well, who have never enabled any modular streams of anything and just want to use Fedora.

The problem will potentially solve itself in both cases by upgrading to Fedora 32 -- that will reset all modular streams and there are no defaults.

What to decide

I'm asking FESCo to decide whether we want to:

  • deliver the fix now (potentially disturbing to an unknown number of users of eclipse package)
  • wait for the unrelated bug of the maven module to be fixed (with a resonable deadline) and deliver the fix then, hopefully not disturbing anyone
  • don't deliver the fix at all (potentially disturbing to an unknown number of users with particular packages installed if they run dnf upgrade within a small window in December)

Note

Let's not make the practical parts of the fix (such as, why do we do it in %posttrans and not %pre etc.) part of the decision here. Let's decide whether (and when) we want to get the eclipse module to be reset for our users.


With @sgallagh we have figured something out. Hold on while I edit this to make it much simpler.

My proposal: Give the unrelated bug of the maven module two weeks to be fixed. Deliver the fix that resets eclipse module once the deadline passes or the unrelated bug is fixed (whichever happens first).

I'm +1 to either @churchyard 's proposal or to just going ahead and implementing the reset immediately. I have some quibbles about the implementation, but those are irrelevant to this discussion.

+1 to implement the reset without delay. If that doesn't get enough support, +1 to @churchyard's proposal of waiting two weeks.

#1800528 has no owner — @mizdebsk says

Providing dependencies for Eclipse is beyond scope of maven module. The purpose of maven module is to provide Maven. I'm not going to add packages unrelated to Maven to maven module.

... which implies that no action on this will happen. I don't see the point of waiting if the maintainer is not asking for more time.

+1 for proceeding without delay, and +1 to wait two weeks if that doesn't get enough votes.

FTR proceeding without delay works for me as well, so I'll count myself as +1 there as well.

@sgallagh if you have some comments on the implementation, please do share them ASAP in the bugzilla. I plan to deliver this as soon as approved here.

@sgallagh if you have some comments on the implementation, please do share them ASAP in the bugzilla. I plan to deliver this as soon as approved here.

I don't really like this approach (it feels wrong to me), but I haven't been able to come up with a better answer. Go ahead.

Metadata Update from @zbyszek:
- Issue tagged with: meeting

a year ago

+1 to reset from my side

+1 with the recommendation that we include a general announcement about the upcoming change, who is impacted that should pay attention (eclipse module users), and a link to a page with more details

This was discussed during today's FESCo meeting (16/3/2020):

  • AGREED: Reset is approved (with details to be written up) (+5, 0, 0)
    The wiki page should be linked from a message emitted by the scriptlet, and the reset should be announced to fedora-devel a few days before the package with the resetting scriptlet is pushed out.

  • ACTION: sgallagh to submit PR for fedora-release to implement the
    reset.

  • ACTION: zbyszek to write up available options in the wiki

I'm leaving this open to coordinate the execution.

Metadata Update from @zbyszek:
- Issue untagged with: meeting

a year ago

Metadata Update from @zbyszek:
- Issue close_status updated to: Accepted
- Issue status updated to: Closed (was: Open)

a year ago

Metadata Update from @bcotton:
- Issue untagged with: F31
- Issue set to the milestone: Fedora 31

8 months ago

Login to comment on this ticket.

Metadata