Am Di., 19. März 2024 um 11:53 Uhr schrieb Iñaki Ucar <iu...@fedoraproject.org>:
>
> Dear all,
>
> I'm looking for options/advice here. See [1], and a bit of context:
>
> - RStudio (now Posit.co) publishes two packages named rstudio (with RStudio
> Desktop) and rstudio-server (with RStudio Server). They are independent and
> have many files in common. Recent versions are based on Electron (for
> Desktop) and have Quarto support.
>
> - In Fedora, we decided to package all the common files in the rstudio
> package, then build rstudio-desktop and rstudio-server for these products,
> with just the specific files. In our build, we rely on QtWebEngine for the
> Desktop version and disable Quarto, because it would be a nightmare to
> package (requires Deno).
>
> Now the issue [1]: there's always been confusion among users that at some
> point install the rstudio package provided by Posit (which provides
> everything), many times because RStudio prompts that there's a new version
> available and they just go click unknowingly. After some time, the package
> manager "updates" it to our version when we hit stable, and RStudio Desktop
> is gone (because rstudio-desktop is not present). Some time ago, I disabled
> the "new version" notification dialog to mitigate this, but these days this
> happens more and more frequently because users want Quarto and specifically
> opt for the package provided by Posit.
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=2270191
>
> What do you think is the best way to mitigate this? Options:
>
> 1. Keep things as they are, just tell the users to exclude the rstudio
> package in the dnf configuration. Pros: no changes required. Cons: it's clear
> that users don't know how to do this. And more documentation rarely solves
> this kind of problem.
>
> 2. Make rstudio Requires rstudio-desktop. Pros: When the package manager
> updates to our version, at least there's a working version of RStudio
> installed. Cons: Server users shouldn't need Desktop installed. Still
> confusing to users.
>
> 3. Rename rstudio as rstudio-common, keep rstudio as a metapackage that just
> Requires rstudio-desktop. Pros: Same as before + Server doesn't need Desktop.
> Cons: Still confusing to users.
>
> 4. Rename rstudio as rstudio-common, make this one Conflicts rstudio. Pros:
> You either install rstudio from Posit, or rstudio-desktop from Fedora. And
> I'm not sure about this, but does installing one remove the other? Or does
> dnf at least show the conflict and the user decides? Cons: `dnf install
> rstudio` doesn't work anymore, so it's less discoverable. And we have a
> similar issue with rstudio-server anyways that cannot be easily solved. But I
> suppose that admins installing rstudio-server know how to prevent package
> updates.
>
> 5. Introduce some version component that makes our package versions be sorted
> < than Posit's. Pros: Upgrades never happen when a user opts for packages
> provided by Posit. Cons: I don't know how to do this without breaking our
> updates. Probably other issues?
>
> Any advice? Other options not considered here?
Wow, contrived situation. I guess this shows again that packaging
should be left to packagers, not upstream :)
4. seems to be the only solution where "problematic but typical" user
behaviour leads to explicit conflicts rather than "funny" behaviour.
`dnf` will bail out and explain the conflicts ("cannot install both
...") and even suggest to use "allow-erasing", which cleans things up.
dnf will not offer "rstudio" updates if there is no such package in
Fedora repos.
Even in this case, one can only hope that users don't switch
inadvertently between "upstream" and Fedora. At least it requires
extra steps with 4 (though I don't now about pkgkit).
Cheers
Michael
--
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
