On Wed, Nov 3, 2021 at 5:15 PM Frantisek Zatloukal <fzatl...@redhat.com>
wrote:

> On Wed, Nov 3, 2021 at 12:32 PM Kamil Paral <kpa...@redhat.com> wrote:
>
>> ~~~~~~~~~~
>> The default graphical package manager for a given software type must
>> appropriately:
>> * install, remove and update software, even if multiple operations are
>> scheduled sequentially or concurrently
>>
>
> I am definitely against blocking on "multiple operations concurrently". I
> don't see this as a frequently used "blocking material", I'd rather leave
> this can of races unopened.
>

I'm not sure if you understood it correctly (or if I even expressed it
correctly). The operations are of course executed sequentially, always
(that's how our package managers work). But they can be *scheduled*
concurrently, i.e. you can install GIMP, and before it is downloaded and
installed, you can also schedule installation of Inkscape. I think this is
not an unusual use case, to schedule several operations at once. E.g. I
just installed a new system and want to install my favorite applications.
Or I decided that I want to play a different game, so I hit Install on
OpenArena and also click Remove on SuperTuxKart.

Is this really what you are against, or have you understood it differently?
I can try to phrase it better.

Now that you made the point, I now realize that there *is* really a case
where multiple operations can be *executed* concurrently. If you schedule
installation of an RPM and a Flatpak at the same time, they are performed
concurrently (tested with GNOME Software). So we could rule those out and
say this is a case when it's not blocking. But honestly, this is a very
small technical distinction that we're able to make (sequential RPMs versus
concurrent RPM+Flatpak), but our users won't. And now that we have Flatpaks
even in official Fedora, and they are even selected by default in GNOME
Software, our users will start to hit this use case more and more
frequently. I think it would be weird to say "we block on gnome-software
blowing up if you press Install on these two packages (before the first
operation is finished), but we don't block if you do the same thing on
these other two packages (because one of them is an official Flatpak)". I'd
rather just cover both cases. It's not like we don't have experience with
race conditions (this very cycle!), and if it is hard to reproduce or hard
to fix, then it's just the usual "shrug, sorry" approach as always.


>
> Apart from that, I am slightly against blocking on "sequentially".
>

See my response above. Imagine that we'd ensure only the first dnf
operation works correctly, but any later one can blow up. Why would we want
to allow that with a graphical package manager?


>
>
>> * start the selected installed software
>>
> If the Graphical package manager exposes such a feature.
>

Sure, exactly as the footnote says. Or do you have a better phrasing for
the footnote to make it even clearer?


>
> Others seem fine, thanks for summarizing this into a more formally defined
> criterion.
>

Thanks.


>
> One more note though, can you post this to the desktop and kde lists (or
> tickets) for their opinions? This shouldn't be put into effect unless our
> blocking desktop maintainers agree imo. For example, KDE folks might want
> to block on a smaller subset of this criterion (I don't know if they do).
>

Sure, I will. I wanted to fine-tune it in the test list first, though.
_______________________________________________
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Reply via email to