Conflicts due to renamed KDE4 ports

[Tijl Coosemans]

On Mon, 16 Apr 2018 20:11:33 +0200 Stefan Esser <se at freebsd.org> wrote:
> Am 16.04.18 um 12:38 schrieb Tijl Coosemans:
>> On Sat, 14 Apr 2018 14:18:22 +0200 Stefan Esser <se at 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.

Like I said, IMHO it's not your problem, so you don't need to work around
it and you don't have to feel frustrated by it.  Without an entry in MOVED
there's no way for portmaster or pkg to know that the old akonadi needs to
be replaced with akonadi-kde4.  If any user contacts you about this you
can forward them to kde@ because they created the problem.

IMHO, entries in MOVED should stay for at least a year, if not several
years, so kde@ should restore the kde4 MOVED entries and give the kde5
ports a -kde5 suffix or something.  Hopefully there aren't that many users
yet because you can't create MOVED entries for this move.