Re: new criterion proposal: Graphical package managers (take #2)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2022-01-20 11:54 a.m., Kamil Paral wrote:
This is another attempt at creating a new release criterion specific for graphical package managers. We already discussed it in November, but we couldn't agree easily on some particular details, and then I was gone for a long time:
https://lists.fedoraproject.org/archives/list/test@xxxxxxxxxxxxxxxxxxxxxxx/thread/LR2FDFMOY4E55ZYBHWOOINZS27FQ6LSB/#LR2FDFMOY4E55ZYBHWOOINZS27FQ6LSB

Here is my new attempt. The new criterion text is longer, but I believe it is overall somewhat weaker (to accommodate some of the previous concerns), just more explicit. As before, please note that we already have package management partly covered in the Basic criteria [1] and Beta criteria [2]. Please read those first, including footnotes. The following new criterion is proposed against the Final milestone:

~~~~~~~~~~~~~~~~~~~~
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)

The following must hold true:
* When multiple operations (covered by this criterion) are requested, all of them must finish correctly. (It's also valid to inform the user that a certain operation is not available at that moment, see the "Supported functionality and design decisions" note). * The displayed state of software or software sources must not differ from their actual state. (E.g. an RPM package must not be shown as installed when it is not, a repository must not be shown as disabled or missing when it is enabled, etc). * Usual GUI interactivity must not break operations covered by this criterion. (E.g. when the GUI allows the user to click some buttons while an operation is running, it must not break that operation). * The package manager must never make the system enter an inconsistent or unbootable state. (E.g. damage the local software database, remove wrong system files, break the bootloader, etc).

Note: Supported functionality and design decisions
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 requirements don't apply if some functionality is intentionally modified as a design decision (e.g. if some software sources can't be disabled as an intentional precaution to users breaking their system). If there is a bug violating the design decisions in one of the covered areas (e.g. a software source which is supposed to be always enabled can be disabled), it's up to the blocker review team to consider whether this bug makes the user experience or system safety considerably worse.

Note: Refer to Basic footnotes
The footnotes for the [similar Basic criterion covering console tools][1] regarding software types, 'appropriate' behavior, scope and so on are all generally applicable to this criterion also.
~~~~~~~~~~~~~~~~~~~~

If you compare it to the previous proposal, the new one avoids talking about "sequential or concurrent" operations. That leaves some more wiggle room when arguing that specific approaches are too niche (Frantisek's concern), i.e. it no longer clearly covers these approaches completely. However, it still makes sure that multiple operations are covered at least at a basic level (which should cover our famous "install and then remove the same package"). The tool can also say "no can do", and when that happens to be some internal error message, we can discuss how clear it is to the user.

I updated the "list installed software" and "configure sources" requirements with suggestions from Ben.

It also explicitly mentions that just basic clicking through GUI must not abort running operations (which was something that got good consensus). And adds an obvious statement about not breaking the system, which was implied in the past but I assumed it's better to have it clearly visible (this one could be moved to Beta, possibly).

Finally it adds a requirement that the package manager must not mislead the user by showing e.g. something as installed when it is not. You can say this was also implied in the past (otherwise the 'install' or 'list' operation is not working correctly). but again, this is just to avoid "it works well, just displays it wrongly" arguments in the future.

What do you think?


[1] https://fedoraproject.org/wiki/Basic_Release_Criteria#software-install-remove-update [2] https://fedoraproject.org/wiki/Fedora_35_Beta_Release_Criteria#Installing.2C_removing_and_updating_software


I've done generic, app-specific and custom installers and lots of install environments on a lot of architectures for about 45 years of my 50 years working as a mission-critical developer and maintainer.  There a lots of people who do not understand the Unix way of doing things or how to take advantage of the Unix filesystem to do things a lot better than Windows, and try to make installation or upgrades behave more like ancient Windows patches.  There are also a growing number of Fedora users who are now discarding the GUI updater in favour of dnf installs, primarily due to the GUI updater having extreme and unnecessary reboot requirements.

The suggested criteria list is pretty generic, and offhand I can't think of a current GUI or CLI installer that does not conform to these requirements.

What this list does NOT cover are the pain points of the current product, such as avoiding reboots.  Currently, the Fedora GUI installer always reboots twice, even though 80% of the updates do not require reboots at all, and similar to the Debian-based distros, tools such as the needs-restarting component of the yum-utils package exist to show that shared libs or open files are out-of-date and either app or full system reboots are required to put the system into a supportable state.  Unlike other distros, there are certain apps, like parts of the Gnome desktop and Firefox, that do not respect a policy of no API changes in a given release, and these apps tend to break routinely because of this broken development model being considered acceptable.  If I look at Ubuntu practices for example, they introduce a needs-rebooting flag that is set when a memory-mapped file is altered, or when an API change is intentionally introduced.  However, having multiple versions of shared libs in use at the same time is not an error, but a really good Unix/Linux feature that is not a valid criteria for a reboot.  The current GUI installer behaves more like Windows, and does not allow this situation when it most certainly should.  Fedora should consider fixing these packages that routinely allow developer errors instead of downloading the resulting problems to the end user, and the installer tools should not be aiding and abetting bad development practices.

Just my humble opinion as a past master of installers or all types and sizes.

--

John Mellor
_______________________________________________
test mailing list -- test@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to test-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/test@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure




[Index of Archives]     [Fedora Desktop]     [Fedora SELinux]     [Photo Sharing]     [Yosemite Forum]     [KDE Users]

  Powered by Linux