On Wed, 20 Mar 2024 at 19:37, Iñaki Ucar <iucar@xxxxxxxxxxxxxxxxx> wrote:
On Tue, 19 Mar 2024 at 12:34, Michael J Gruber <mjg@xxxxxxxxxxxxxxxxx> wrote:Am Di., 19. März 2024 um 11:53 Uhr schrieb Iñaki Ucar <iucar@xxxxxxxxxxxxxxxxx>:
>
> 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).Thanks, Michael. Do you find option 5 unadvisable? Because a possible way I found is the following.Upstream versioning is year.month.day-build. Example: 2023.12.1-403. So they name their package rstudio-2023.12.1-403. In a way, the build identifier works as a release number for them. Our package is rstudio-2023.12.1+403-1, so the same version is always sorted > than theirs.What if, for the next release, I change the versioning scheme to e.g. rstudio-2024.04.01~500-1, which would always be sorted < than theirs? Our package will be updated nicely, but then, if a user manually installs their packages (rstudio or rstudio-server), they will never be updated by our packages. Any shortcomings I don't see?
- rename rstudio -> rstudio-common
- add "Conflicts: rstudio" to rstudio-common
When a new version is released:
- change the version scheme to using ~ instead of +, so that their rstudio-server is not updated with our rstudio-server
Iñaki Úcar
-- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-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/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
