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

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

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

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

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.

_______________________________________________ mailing list
To unsubscribe, send any mail to ""

Reply via email to