On Tue, 19 Mar 2024 at 12:34, Michael J Gruber <m...@fedoraproject.org> wrote:
> 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). > 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? Best, -- Iñaki Úcar
-- _______________________________________________ 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
