On Wed, 20 Mar 2024 at 19:37, Iñaki Ucar <iu...@fedoraproject.org> wrote:
> > > 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? > I might even do both things. In a first iteration: - 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@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
