Date: Sat, 14 Apr 2018 14:18:22 +0200 From: Stefan Esser <se@freebsd.org> To: Ports FreeBSD <freebsd-ports@FreeBSD.org>, FreeBSD Port-Manager <portmgr@FreeBSD.org> Subject: Conflicts due to renamed KDE4 ports Message-ID: <a9ce1576-a254-4e79-3e50-b90d49827a1e@freebsd.org>
next in thread | raw e-mail | index | archive | help
The way the new KDE5/KF5 ports have been introduced a few weeks back has caused me quite some effort (more than 100 hours of work), and now there have been further changes to implement KDE5 support (which I generally appreciate), which cause further complications and seem not to be well thought out. These problems affect at least all portmaster users, but I guess portupgrade is affected as well and a "pkg upgrade" dry-run indicates, that it will also cause breakage to binary upgrades of KDE4 installations. I'm trying to get portmaster operational again, after it has been unusable for systems with KDE4 ports for a few weeks. Since the way portmaster works prevents an easy solution, I'm currently rewriting it from scratch (and had it mostly working for the normal upgrade tasks, with some of the more "special" like cleaning up stale distfiles missing). This new version is now again broken, because of changes that I do not know how to automatically deal with. (And IMHO it is impossible to deal with them, without hard-coding specific work-arounds for the affected ports. This is against the spirit of a generic port management tool.) A number of KDE4 ports have been moved to port directories that have an extra -kde4 appended. The package names changed at the same time, and that caused problems for portmaster, since if there was a dependency that referred to the new origin with -kde4 attached, it would be in conflict with the installed package. (The -kde4 version would be built and the install would fail because the non-kde version was not recongnized as a previous version of the same port and was not automatically deinstalled first. This is fixed in my new portmaster version, which finds the old origin in the MOVED file and checks whether there is a port that was installed from some meanwhile "moved" origin.) Individually updating those ports first, could solve this issue, but there was not list of affected ports and thus it was up to the user to detect the build failures as they occurred, delete the old version and restart the portmaster run. (My new version deals with this, based on the MOVED file, as described above.) Now the situation has become much worse: Now there are KDE5 versions of quite a number of prior KDE4 ports, which share the origins and package names of these prior KDE4 programs, and can only be recognized by their version numbers being different from 4.*). This leads to breakage in a number of ways: Ports depending on say KDE4 akonadi but installed at a time when the origin still was databases/akonadi will (probably) break when akonadi is upgraded and replaced by the KDE5 version of akonadi. There is no way that portmaster could know, that the KDE4 version is now built from databases/akonadi-kde4 and installed as akonadi-kde4-4.* (instead of just akonade-4.*). New ports will try to install akonadi-kde4 as a dependency, which may succeed, after databases/akonadi has been upgraded to the KDE5 version, but before that has happened, there will be conflicting files and the dependency on akonadi-kde4 cannot be satisfied by the ports system. OTOH, I now have a KDE5 version of akonadi, which has not been requested by the user (who may want to stay at KDE4 at the moment). This KDE5 version has been built, because there was a KDE4 version, and the port system did not know, that these two ports share their origin and package name (sans version), but are not directly related. Again OTOH, the upgrade of akonadi to the KDE5 version will break all ports, that rely on the KDE4 version being installed. These seem to be: $ pkg info -r akonadi akonadi-1.13.0_6: kdepimlibs-kde4-4.14.10_15 smokekde-4.14.3_3 kde-workspace-4.11.22_14 kdeplasma-addons-4.14.3_6 kdepim-runtime-kde4-4.14.10_9 kdepim-kde4-4.14.10_11 ruby24-korundum-4.14.3_2 py27-pykde4-4.14.3_7 baloo-kde4-4.14.3_7 on my system ... A number of KDE4 ports have been copied to new origins (with -kde4 attached) with there old directories still present and functional. That does also cause problems for automatic port build tools like portmaster. The old ports seems to be still valid and is not marked to be in conflict with its copy. Since the package names have been changed (by appending -kde4) it is not possible to detect, that these are in fact just renamed versions of the previous port. Since there is no MOVED entry, the last possibility that might provide a hint is lost. (There can be no MOVED entry, since the old name is to be re-used for the KDE5 version of that program.) I think it is a very bad idea to do any of the following: 1) Rename a port without an entry in MOVED (even though dependencies are updated) if the package name (sans version) is changed at the same time. 2) Copy a port resulting in two origins that build the same package and that are not marked as mutually conflicting (whether with identical or changed package names - but the latter might make matters worse). 3) Perform incompatible upgrades of lots of ports of a framework to an incompatible new major release of the framework (i.e. have all the prior KDE4 ports, many of them built as a dependency, now lead to KDE5 versions of those being installed without being requested by the user). There seem to be problem for package users, too, but I did not only perform a dry-run of "pkg upgrade", e.g.: # pkg upgrade kdeartwork-kde4 [...] New packages to be INSTALLED: xcursor-themes: 1.0.4_2 py27-matplotlib: 2.1.2_2 alsa-plugins: 1.1.1_2 kf5-knewstuff: 5.44.0 kf5-kdeclarative: 5.44.0 kf5-kpackage: 5.44.0 kf5-kinit: 5.44.0 kf5-kdelibs4support: 5.44.0 kf5-kded: 5.44.0 kf5-kdesignerplugin: 5.44.0 kf5-kdewebkit: 5.44.0 kf5-kplotting: 5.44.0 kf5-kemoticons: 5.44.0 kf5-kunitconversion: 5.44.0 kf5-kitemmodels: 5.44.0 kf5-knotifyconfig: 5.44.0 nepomuk-core-kde4: 4.14.3_17 kfilemetadata-kde4: 4.14.3_16 akonadi-kde4: 1.13.0_7 kf5-kcmutils: 5.44.0 libkexiv2-kde4: 4.14.3_5 qca-qt5: 2.1.3 p5-SQL-Translator: 0.11024 kde-workspace-kde4: 4.11.22_18 kde-wallpapers-kde4: 4.14.3_3 kde-base-artwork-kde4: 4.14.3_3 kf5-khtml: 5.44.0 kf5-kjs: 5.44.0 woff2: 1.0.2_1 brotli: 1.0.4,1 py27-backports.functools_lru_cache: 1.5 py27-backports: 1 py27-decorator: 4.2.1 raptor: 1.4.21_6 Why do I get all those kf5- packages installed, when asking for an upgrade of a specific KDE4 port??? BTW: The upgrade wants to install akonadi-kde4-1.13.0_7 over the existing akonadi-1.13.0_6. I did not test whether pkg will silently replace the old version, or whether it will stop with a conflict because both versions have the same files. The same applies to quite a number of existing KDE4 packages that got a kde4 suffix in their package names (and are still installed from before that date on my system) they are all already present! And last: There was no entry in UPDATING (I see, tcberner now has added some text that at least references this problem and gives one example how to fix the package database). Seems there was a MOVED entry for akonadi for some time, which now is gone to allow building of the KDE5 version of akonadi from the origin made unusable by the MOVED entry. Not everybody rebuilds working ports every week, and portmaster has been broken by the simultaneous renaming of port origins and package names of the KDE4 ports (and thus portmaster users have either manually rebuilt all the affected ports, or they are still blocked at a state as of when this renaming happened), so the (now already gone) entries in MOVED where of limited use. To resolve this issue (for the time being) I request a complete list of "pkg set --change-origin <port>:<port>-kde4 <pkgname>" for all affected KDE4 ports. And I think that the new KDE5/KF5 ports should not have re-used the KDE4 origins. This may be possible in the case of a major upgrade of some simple port without a huge number inter-dependencies. But in the case of a complex framework like KDE, I had expected that not only the old ports are renamed to have a kde4 suffix, but also that the new ports have either a kf5- prefix or kde5 suffix in their names. (The suffix may be dropped, if and when such ports have been converted to use FLAVORs.) I'm quite annoyed by such changes, that may have been tested with poudriere (but I severely doubt it, given the above shown dependencies of kdeartwork-4 on kf5 ports), but they void literally hundreds of hours of effort spent on trying to keep portnaster a viable tool for specific port building and upgrade tasks. I'm using it myself as a much lighter-weight alternative to poudriere and to manually building ports that are under development, before finally testing the new port with poudriere. And I'd hate to loose this possibility. (And while I could use poudriere built packages to upgrade my system, I prefer to keep it current with portmaster, too.) This is another case (after the implementation of FLAVOR support that does not seem well-designed and causes lots of effort and inefficiencies in port management tools like portmaster), which makes me consider giving up my efforts to keep portmaster alive. STefan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?a9ce1576-a254-4e79-3e50-b90d49827a1e>