Conflicts due to renamed KDE4 ports

[Tobias C. Berner]

Moin moin

Here's a script which should automatically fix the origin for the
kde4-versioned ports (based on the MOVED entries of r465345):
   http://people.freebsd.org/~tcberner/scripts/fix_kde4_origins.sh

It //should// set the origins properly for the moved ports, and the output
should be on the lines of
# ./fix_kde4_origins.sh
[...]
- sysutils/baloo-widgets [sysutils/baloo-widgets-kde4] is not installed.
+ Changing origin of nepomuk-core-4.14.3_14 from sysutils/nepomuk-core to
sysutils/nepomuk-core-kde4.
- sysutils/kfloppy [sysutils/kfloppy-kde4] is not installed.
- sysutils/ksystemlog [sysutils/ksystemlog-kde4] is not installed.
+ Changing origin of baloo-4.14.3_5 from sysutils/baloo to
sysutils/baloo-kde4.
+ Changing origin of kfilemetadata-4.14.3_13 from sysutils/kfilemetadata to
sysutils/kfilemetadata-kde4.
[...]


Please let me know if that works for you, or how I could improve it.


mfg Tobias



On 17 April 2018 at 17:43, Tijl Coosemans <tijl at freebsd.org> wrote:

> On Tue, 17 Apr 2018 16:19:39 +0200 Tobias C. Berner wrote:
> > Long answer: KDE is shipped in mulitple, let's call them groups:
> >   - frameworks (libraries to build kde and qt applications) -- we call
> > these ports kf5-foo
> >   - plasma (the desktop) -- we'll call these ports plasma5-foo
> >   - applications (the applications)
> >
> > Now, previously during KDE SC4 days, this was a whole "blob". This is why
> > it made sense to call them all kde4-foo or foo-kde4.
> > Now with this new split there is no real notion to call an application
> > foo-kde5. For example during the transition in the last few
> > years many KDE Application releases were a mix of Qt4 and Qt5 (i.e.
> > kdelibs4 and kf5 based applications). So we would have had
> > a kate-kde5 that was using kdelibs-kde4 ... well that would have been
> > confusing too.
> >
> > The same thing will eventually happen when the next KDE Frameworks will
> > roll around I expect, where the applications get updated one after
> > another, with mixed releases in between.
> >
> > We opted for the same method as other ports use. A new version appears
> that
> > is incompatible, move "bar/foo" to "bar/foo3" and update "bar/foo" in
> > place.
>
> I don't think this is the norm.  All the big ports (perl, python, php,
> gcc, mysql, gtk, qt,...) just leave bar/foo and create bar/foo4.  In
> place updating to an incompatible version can be a complete surprise
> for users (POLA violation) and leave them with a broken system.
>