Release criteria change proposal: Honor protected packages in GUI package managers

Project Discussion
, , ,
1

Update: This proposal has been accepted.

During a blocker discussion for bug 2400488 (discussion ticket), regarding gnome-software ignoring protected packages and allowing to silently remove a big chunk of the gnome environment, we agreed that we want to add new a requirement to the existing release criterion, so that we can accept the bug as a blocker. Here’s the proposal for the criterion adjustment.

Under the Installing, removing and updating software section of the Final release criteria, a new bullet point would be added (marked as bold):

The default graphical package manager for a given software type must appropriately:

  • Install, remove and update software
  • List locally-installed software coming from the official Fedora repositories
  • List available software (possibly in categories, a curated list, etc)
  • Display metadata relevant to the selected software (e.g. the description, screenshots, the size)
  • Start the selected installed software
  • Configure software sources by enabling/disabling pre-defined official repositories and then adjust the available software pool accordingly
  • Notify the user when system updates are available (taking into account the intended frequency of such notifications)
  • Honor definitions of system software protected from removal, and act in those cases accordingly

The following must hold true:

<cut for brevity, no change there>

Please note that there are some important footnotes in that criterion as well, one of them starting with this:

All requirements apply only if such a functionality is supported by the package manager; it does not imply that the package manager must support all this functionality.

The idea is that the default graphical package manager (GNOME Software, KDE Discover) will need to work correctly regarding protected packages (look into /etc/dnf/protected.d/, and it can also be defined inside appstream metadata) if it support it, i.e. a bug/regression in this area is a blocker. It isn’t mandatory to support this feature, though, and developers can make other/different design decisions, as long as they’re intentional.

People also suggested that this shouldn’t be targeted at just GUI package managers but also DNF, and while valid, we’re currently aiming for a minimal change in criteria (the Go/NoGo meeting is next week), and can discuss more complex criteria changes after F43 is released.

Please voice your approval or disapproval of the proposed change, or propose a different wording of the change. Thank you.

8 Likes
2

It’s a great idea, but you could wait for a month to implement it if you have other pressing work.

3

The proposal needs to be accepted in ~one week, otherwise we’ll have to drop the blocker status from bug 2400488.

4

Sounds reasonable to me. There should be consistency between the various ways of installing and removing software on Fedora.

5

But it can’t actually be a blocker yet if you need this new criterion :wink:

Do what you need to do, it’s a good idea.

I’m +1

6

I agree with the proposed criteria.

7

It seems fine to add the new wording for the avoidance of doubt.

Shouldn’t the bug be a blocker even without that wording change though?

The existing wording requires:

If the software manager removes most of GNOME when the user merely tells it to remove a font, surely it does not “appropriately remove software”.

1 Like
8

Too vague and a bit subjective - the change makes it an absolute with little to zero wiggle room.

2 Likes
9

During the blocker review, we felt that the current wording is not sufficient (therefore this proposal).

11

Hi Jordan,

The community here is very ‘on topic’ and professional.

Could I ask as a favour that you only make relevant comments?

There is the ‘off topic’ watercooler space where it is fine to post about videos you would like to share.

Thanks,

Mat

12

Looks reasonable to me.

Is this likely to be something that can get fixed in time?

13

Yes, patches are available and await testing.

14

I’m +1. The GNOME Software test protocol should be updated following this change.

15

Thanks everyone for your discussion, this is now accepted and implemented.

3 Likes