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 am unclear from this proposal on what is supposed to happen if a
package is not completely installed. E.g: a powerdown or other outage
causes the post-install script in an installed rpm to not be run. A few
packages like the kernel can take ten minutes to install properly, and
you may not have enough battery left to get that done when the power
goes out. The package and its dependencies are installed, but not
initialized correctly. Does it force an installer continuation or redo
at boot time for these partial installs, does in uninstall the app and
its whole chain of dependencies, or does it just leave things in a
corrupted state?
Similarly, if an already-installed package is corrupted and then
upgraded, what is the expected handling?
--
John ellor
_______________________________________________
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
