Am 16.04.18 um 12:38 schrieb Tijl Coosemans:
> On Sat, 14 Apr 2018 14:18:22 +0200 Stefan Esser <> 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
_______________________________________________ mailing list
To unsubscribe, send any mail to ""

Reply via email to