On Wed, Dec 9, 2020 at 3:42 PM Miro Hrončok <mhroncok(a)redhat.com> wrote:
On 12/9/20 9:56 PM, Troy Dawson wrote:
> On Wed, Dec 9, 2020 at 11:21 AM Miro Hrončok <mhroncok(a)redhat.com> wrote:
>> On 12/9/20 7:44 PM, Ben Cotton wrote:
>>> == How To Test ==
>>> * Install all nodejs libraries in Fedora 33. Try to update to Fedora 34.
>> What is the plan wrt Obsoletes of the removed packages?
>> Miro Hrončok
> We do not plan on obsoleting them.
> Obsoleting them has the potential to break third party software.
> dnf should also clean things up by seeing that the dependencies of an
> upgraded package have gone away.
> If dnf misses it, these are libraries, not binaries. If nothing is
> using them, they just take up some disk space. If a user really wants
> to clean them up, those types of users usually have their favorite
> ways of doing so.
I worry about this specific case: There are several JS libraries unbundled in
python-notebook. Due to RPM/DNF limitations, they can onyl be unbondled if the
JS packages are obsoleted:
I can definitively make sure the relevant packages are obsoleted by
fedora-obsolete-packages but that opens a can of worm, because if only some
removed packages are obsoleted, other removed packages will block the upgrade
path to Fedora 34/35. And they will need to be obsoleted as well.
I rutinelly spend several hours each release to figure out and fix upgrade path
issues by obsoleting packages via fedora-obsolete-packages. I'd like some help
with this by the change owners / NodeJS SIG. Can I count on that?
bundling scripts and thus do not feel confident in documenting and
removing them at this time. There are currently only 20 of them, and
I think we will add them to our exceptions list, along with the binary
nodejs libraries. Hopefully by F35 or F36 we will be able to get to
But other than those, yes, I believe the Nodejs sig can help with
upgrade path issues and obsoleting packages that need to be obsoleted.