Am 16.04.18 um 12:38 schrieb Tijl Coosemans: > On Sat, 14 Apr 2018 14:18:22 +0200 Stefan Esser <s...@freebsd.org> wrote: >> 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. > > Removing entries from MOVED after only a few weeks is a bad idea, but > it's not something you have to worry about. As long as portmaster > behaves more or less the same as pkg you're good.
I only tried a dry run, but it appears, that pkg does not deal with this situation correctly. Grzegorz Junka reported, that it did not work for him and he had to manually delete all KDE ports and re-install them from his repository built with poudriere. A correct decision is impossible given on the information in the ports. It is correct to upgrade e.g. databases/akonadi (akonadi-1.13.0_6) to databases/akonadi-kde4 (akonadi-kde4-1.13.0_7), but neither the origin nor package name nor a MOVED entry provide that information. It is not correct to replace databases/akonadi (akonadi-1.13.0_6) by databases/akonadi (akonadi-17.12.3), but this can only be seen by checking the forward and backward dependencies (which are for KDE5/QT5 instead of KDE4/QT4 of the installed port). The same considerations applied to another port may lead to different results. While pkg requires exact dependencies to be installed, it is possible to use alternatives to satisfy dependencies with portmaster. And this feature is heavily used, e.g. to use a different version of samba than the default hard-wired into package dependencies. But this flexibility needs a basis for deciding, whether such a replacement is valid and how to perform upgrades in that situation. If akonadi is installed only as a dependency of other ports, then pkg will install the akonadi-kde4 version. But since the old version is installed as an in-use dependency of other KDE4 ports, it will not be removed before the installation of the new version is attempted (which will lead to an install conflict, since files of an installed port are to be overwritten). It is possible to manually and forcefully delete akonadi-1.13.0_6 before starting pkg upgrade for the KDE4 ports that depend on it. In that case, there is no conflict. But pkg autodelete cannot be used, since to remove the dependency on the old version, the (conflicting) new version must be registered in the ports that depend on akonadi. If akonadi has been directly installed and not (only) as a dependency, the akonadi-17.12.3 will be considered to be an upgrade of akonadi-1.13.* (same origin and same package name, except for the version numbers). This will remove the required dependency from the KDE4 ports and will register the KDE5 version as new dependency of those ports (although it completely useless in that role). When not even pkg can deal with this situation, how should portmaster? The packages are built without consideration for the requirements of a running system, and pkg sees all the meta-information of all installed packages and the one being processed and can e.g. see, that files will conflict (which portmaster can only do after completely building the port, which means that this is long after the decision to use that port has been required). The lack of consideration given by port maintainers is quite frustrating, since it requires a lot of effort to work around the issues caused. Regards, STefan _______________________________________________ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
