I ran sudo dnf system-upgrade download --releasever 42 --disablerepo=*update* in a Fedora 41 KDE installation with R-4.4.2-1.fc41.x86_64 installed. dnf problems showed R-core-devel-4.4.2-4.fc42.x86_64 requires tcl-devel < 1:9 and tk-devel < 1:9 which conflict with tcl-devel-1:9.0.0-7.fc42.x86_64 and tk-devel-1:9.0.0-3.fc42.x86_64 Problem 2: package R-core-devel-4.4.2-4.fc42.x86_64 from fedora requires tcl-devel < 1:9, but none of the providers can be installed - package tcl-devel-1:9.0.0-7.fc42.x86_64 from fedora conflicts with tcl8-devel provided by tcl8-devel-1:8.6.15-10.fc42.i686 from fedora - package tcl-devel-1:9.0.0-7.fc42.x86_64 from fedora conflicts with tcl8-devel provided by tcl8-devel-1:8.6.15-10.fc42.x86_64 from fedora - problem with installed package - problem with installed package - tcl-devel-1:8.6.14-5.fc41.x86_64 does not belong to a distupgrade repository - R-core-devel-4.4.2-1.fc41.x86_64 does not belong to a distupgrade repository Problem 3: package R-core-devel-4.4.2-4.fc42.x86_64 from fedora requires tk-devel < 1:9, but none of the providers can be installed - package tk-devel-1:9.0.0-3.fc42.x86_64 from fedora conflicts with tk8-devel provided by tk8-devel-1:8.6.15-5.fc42.i686 from fedora - package tk-devel-1:9.0.0-3.fc42.x86_64 from fedora conflicts with tk8-devel provided by tk8-devel-1:8.6.15-5.fc42.x86_64 from fedora - package R-devel-4.4.2-4.fc42.x86_64 from fedora requires R-core-devel(x86-64) = 4.4.2-4.fc42, but none of the providers can be installed - problem with installed package - problem with installed package - tk-devel-1:8.6.14-2.fc41.x86_64 does not belong to a distupgrade repository - R-devel-4.4.2-1.fc41.x86_64 does not belong to a distupgrade repository The upgrade was prevented due to these problems. Reproducible: Always Steps to Reproduce: 1. Boot a Fedora 41 KDE installation with R-core-devel-4.4.2-1.fc41 installed and updates-testing enabled 2. Log in to Plasma 3. Start Konsole 4. sudo dnf upgrade --refresh 5. sudo dnf system-upgrade download --releasever 42 --disablerepo=*update* Actual Results: R-core-devel-4.4.2-4.fc42.x86_64 from fedora requires tcl-devel < 1:9 and tk-devel < 1:9 which conflict with tcl-devel-1:9.0.0-7.fc42.x86_64 and tk-devel-1:9.0.0-3.fc42.x86_64 Expected Results: No dnf problems should've happened. The updating of R for Tcl/Tk 9.0 was discussed at https://bugzilla.redhat.com/show_bug.cgi?id=2337765
Reassigning to tcl/tk. What are we supposed to do here? If the packages conflict, then it defeats the whole purpose of a compat package.
I also saw this on my laptop. It prevents a clean upgrade. But normal users that don't do development don't need to install -devel packages. Do we have any packages that will require R-core-devel and the new tk-devel to be installed together?
R is a bit different in this regard, because CRAN serves source packages that are compiled in the users' machine. As a result, normal users do have -devel packages and will face this issue, so this is quite a problem.
Unfortunately this is how devel packages work. You cannot have compat and non-compat devel package installed at the same time. It isn't Tcl/Tk specific. We could resolve it either by switching conflicting packages to Tcl/Tk 9 or Tcl/Tk 8. The latter is easier.
I'm sorry, but I don't agree. devel or not devel, this is not how compat packages work. They are supposed to be parallel-installable, and are supposed to provide some magic or some instructions to point to the compat version (in this case of the headers as well as the libraries). Otherwise, this change is going to break the upgrade path for all users of R in Fedora, basically. I think this is not acceptable.
(In reply to Iñaki Ucar from comment #5) > I'm sorry, but I don't agree. devel or not devel, this is not how compat > packages work. They are supposed to be parallel-installable, and are > supposed to provide some magic or some instructions to point to the compat > version (in this case of the headers as well as the libraries). Otherwise, > this change is going to break the upgrade path for all users of R in Fedora, > basically. I think this is not acceptable. And what do you expect to build from the simultaneously installed Tk-devel and Tk-compat-devel? Tk 9? Tk 8? Tk 9 or Tk 8 according to the random generator?
I expect tk 9 by default or tk 8 by pointing to the proper place.
(In reply to Iñaki Ucar from comment #7) > I expect tk 9 by default or tk 8 by pointing to the proper place. If you have to point now newly to different place, it isn't compat.
I am afraid you have a bit mess in what the compat package mean in Fedora.
But in case there isn't other better way, I could do a really dirty hack and allow simultaneous installation of Tcl/Tk compat/non-compat devel packages and if both are installed the Tcl/Tk 9 will built. It will be very dirty, and I think that in such case there is no need for the compat devel package to be installed. But without upstream Tcl/Tk support there is probably no other way (other than fixing correctly the deps).
The fact is that this change to a version that is not even stable breaks things. And we are finding out with a beta freeze in place. Not to mention that the adaptation took me 6 commits given the instructions in the change proposal. Sorry to be blunt, but please put yourself in my place. Anyway, life's too short. I'm removing the dependency in the devel packages that has been there for ages, and hope for the best (i.e. that no R package breaks).
(In reply to Iñaki Ucar from comment #11) > The fact is that this change to a version that is not even stable What is your information from? AFAIK it's 9.0.1 stable release i.e. the first major release after cca. 27 years. e.g.: http://www.tcl-lang.org/software/tcltk/9.0.html https://en.wikipedia.org/wiki/Tcl > breaks things. Yeah, that's why we have compat and why it was proposed and accepted as a system-wide Fedora change. > And we are finding out with a beta freeze in place. I clearly communicated this intention on the fedora-devel mailing list, asked for best practices, tips and feedback. All the steps that were agreed on there were summarized into the change proposal and approved by FESCO, all in the planned time frame. I am really sorry, that you didn't bring up your, quite exotic, use case earlier. Then we could scratch the drop-in compat replacement idea and go with a Tcl/Tk 8 fork and custom patches in the Tcl/Tk 8 consumers, or get some more robust solution upstream. But it wouldn't be doable in one person in a few weeks. > Not to mention > that the adaptation took me 6 commits given the instructions in the change > proposal. Sorry to be blunt, but please put yourself in my place. > I am really sorry that it didn't go as smooth as it could in the ideal world, but please note that I am doing my best. > Anyway, life's too short. I'm removing the dependency in the devel packages > that has been there for ages, and hope for the best (i.e. that no R package > breaks). Great, problem resolved, at least for now.