Package conflict management advice

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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? 

Best,
--
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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux