Re: Package conflict management advice
On Wed, 20 Mar 2024 at 19:37, Iñaki Ucar wrote:
>
>
> On Tue, 19 Mar 2024 at 12:34, Michael J Gruber
> 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
Re: Package conflict management advice
On Tue, 19 Mar 2024 at 12:34, Michael J Gruber
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:
Re: Package conflict management advice
Am Di., 19. März 2024 um 11:53 Uhr schrieb Iñaki Ucar :
>
> 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
Package conflict management advice
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@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
