Conflicts due to renamed KDE4 ports

Tue Apr 17 07:24:47 UTC 2018

[where did this discussion take place, earlier? this is the first I've seen it 
-- oh, the ports@ list]

So, there are roughly two migration paths: supposing someone has x11/kde4 
installed, which has dependencies on many applications and a Plasma 4 desktop, 
kde@ wants (wanted) to make it possible to migrate to a still-KDE4 desktop, 
while renaming everything to have a -kde4 suffix. The other path is to migrate 
to the latest-and-greatest-from-KDE .. we don't have a metaport for that, and 
if we do get one it probably won't be called x11/kde5.

For single applications, the migration looks similar: you had, around january 
2018, port <foo>. That's the KDE4 version. Now there is port <foo>-kde4, if 
you want to stick to KDE4 software (which is no longer released upstream, and 
is based on an EOL toolkit, but some people feel quite strongly about this). 
Ports <foo> are returning, without a suffix, to mean "the latest-and-greatest-
version-of-<foo>". This is consistent with other ports which have a <foo>, 
sometimes a <foo>-devel for upcoming things, and a <foo>-<version> for older 
versions if you have specific dependencies on old versions.

Historically, things were a mess with naming with the KDE ports. We think 
we've got a good scheme now: <foo>-kde4 (and in the far future, <foo>-kf5) for 
versions of the software based on an older stack, and <foo> for the current 
one. But the pain of getting from the mess to something better organized has 
to happen at some point.

I think we've been saying this -- that things were going to happen this way -- 
for nearly a year. Maybe not in all the right places, though. 

On Monday, 16 April 2018 21:13:29 CEST Tijl Coosemans wrote:
> 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.

This is correct if, and only if, you want the migration path of staying-with-
KDE4.

> > 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).

. and this is the correct move if you want to go with KDE Applications (the 
current releases). The package manager and the ports-management tools can't 
know which one you want, I don't think.

Consider vim -- it doesn't have one blessed-and-eternal version called "vim", 
editors/vim is the most-recent version. We've adopted that same convention.

What I *do* understand is that the package and ports-management tools don't 
deal well with this. There was a window where we tried to do all the moving.

> > 
> > 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.

There is no KDE5 (there is a KDE Plasma Desktop 5, and there are KDE 
Applications, all built on KDE Frameworks 5). As far as upstream is concerned, 
for all applications released by the KDE community, the KDE Applications 17.12 
(KF5-based) version is "the" version of that application.

[ade] (@FreeBSD to be able to post to the list, but with my KDE-hat on)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-freebsd/attachments/20180417/f51184f9/attachment.sig>