Re: magic syntax for most recent git from sourceforge? [solved]

[Gary Aitken]

On 04/16/18 13:17, Gary Aitken wrote:

Can anyone give me the magic formula for fetching the most recent git
distro from sourceforge for a ports Makefile?

The porter's handbook talks about how to fetch git repos from github
but not about how to get them from sourceforge.

I've tried a few things but can't get the right combo of MASTER_SITES
and PORTNAME, DISTFILE, and DISTVERSION

The git clone cmd is:
   git clone https://git.code.sf.net/p/nufraw/git nufraw-git

This particular git version says it is 0.41 but attempting to fetch
with from
   PORTVERSION=    0.41
   MASTER_SITES=   https://sourceforge.net/projects/nufraw/files/latest/
doesn't work; PORTVERSION=  0.40 does.
I've also tried with
   DISTVERSION=    07ebb73a
with no joy.


Many thanks to Jeremy Chadwick for guidance.
Appropriate values for the above example are:

DISTVERSION= 0.41
MASTER_SITES= SOURCEFORGE/nufraw

A problem also encountered while searching for a solution was a stale distinfo
left over from using the 0.40 version; moving it aside allowed the fetch to
complete.  Apparently the distinfo file is checked during the fetch process
if it exists, not just at extract time.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

kbuild

[Walter Schwarzenfeld]

fails to build

n file included from 
/ram/usr/ports/devel/kBuild/work/kBuild-0.1.9998/src/kmk/commands.c:19:0:
/ram/usr/ports/devel/kBuild/work/kBuild-0.1.9998/src/kmk/commands.c: In 
function 'delete_target':
/ram/usr/ports/devel/kBuild/work/kBuild-0.1.9998/src/kmk/make.h:872:52: 
error: 'errno' undeclared (first use in this function)

 #define EINTRLOOP(_v,_c)   while (((_v)=_c)==-1 && errno==EINTR)
    ^
/ram/usr/ports/devel/kBuild/work/kBuild-0.1.9998/src/kmk/commands.c:856:3: 
note: in expansion of macro 'EINTRLOOP'

   EINTRLOOP (e, stat (file->name, ));
   ^
/ram/usr/ports/devel/kBuild/work/kBuild-0.1.9998/src/kmk/make.h:872:52: 
note: each undeclared identifier is reported only once for each function 
it appears in

 #define EINTRLOOP(_v,_c)   while (((_v)=_c)==-1 && errno==EINTR)
    ^
/ram/usr/ports/devel/kBuild/work/kBuild-0.1.9998/src/kmk/commands.c:856:3: 
note: in expansion of macro 'EINTRLOOP'

   EINTRLOOP (e, stat (file->name, ));
   ^
/ram/usr/ports/devel/kBuild/work/kBuild-0.1.9998/src/kmk/make.h:872:59: 
error: 'EINTR' undeclared (first use in this function)

 #define EINTRLOOP(_v,_c)   while (((_v)=_c)==-1 && errno==EINTR)
   ^
/ram/usr/ports/devel/kBuild/work/kBuild-0.1.9998/src/kmk/commands.c:856:3: 
note: in expansion of macro 'EINTRLOOP'

   EINTRLOOP (e, stat (file->name, ));
   ^
/ram/usr/ports/devel/kBuild/work/kBuild-0.1.9998/src/kmk/commands.c:865:11: 
warning: implicit declaration of function 'unlink' 
[-Wimplicit-function-declaration]

   if (unlink (file->name) < 0
   ^~
/ram/usr/ports/devel/kBuild/work/kBuild-0.1.9998/src/kmk/commands.c:866:16: 
error: 'ENOENT' undeclared (first use in this function)

    && errno != ENOENT) /* It disappeared; so what.  */
    ^~
gmake[5]: *** [Makefile:845: commands.o] Error 1
gmake[5]: Leaving directory 
'/ram/usr/ports/devel/kBuild/work/kBuild-0.1.9998/out/freebsd.amd64/release/bootstrap/kmk'

gmake[4]: *** [Makefile:1482: all-recursive] Error 1
gmake[4]: Leaving directory 
'/ram/usr/ports/devel/kBuild/work/kBuild-0.1.9998/out/freebsd.amd64/release/bootstrap/kmk'

gmake[3]: *** [Makefile:650: all] Error 2

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Conflicts due to renamed KDE4 ports

[Grzegorz Junka]

On 17/04/2018 09:11, Tijl Coosemans wrote:

On Tue, 17 Apr 2018 00:42:48 +0200 Adriaan de Groot  wrote:

[where did this discussion take place, earlier? this is the first I've seen it]

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 . That's the KDE4 version. Now there is port -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  are returning, without a suffix, to mean "the latest-and-greatest-
version-of-". This is consistent with other ports which have a ,
sometimes a -devel for upcoming things, and a - 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: -kde4 (and in the far future, -kf5) for
versions of the software based on an older stack, and  for the current
one. But the pain of getting from the mess to something better organized has
to happen at some point.

What happens when you run pkg upgrade on a 6 months old installation of KDE4?


As stated earlier, I had a few kde4-specific applications installed on 
my system (kwrite, kate, konsole, ...). I am using poudriere and wasn't 
upgrading for like 6 months. I tried a few weeks ago and it failed. I 
was getting errors that a file, here listed a path to a file in a new 
package, is already installed by another package. Deleting the file was 
leading to another similar error. Manually uninstalling old packages and 
reinstalling with updated names of course solved the issue but I only 
had a few of those applications.

GrzegorzJ
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: FreeBSD Port: mod_dav_svn-1.10.0

[Lev Serebryakov]

On 17.04.2018 21:13, Douglas Thrift wrote:

> It seems like the update to 1.10.0 has lost
> libexec/apache24/mod_dontdothat.so, but I don't see any mention of its
> removal in the release notes for Subversion. Was this an accident or did
> I miss something?
 It was excluded from default build... I'll try to restore it build.

-- 
// Lev Serebryakov
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: 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  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.
>
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

FreeBSD Port: mod_dav_svn-1.10.0

[Douglas Thrift via freebsd-ports]

Hello,

It seems like the update to 1.10.0 has lost
libexec/apache24/mod_dontdothat.so, but I don't see any mention of its
removal in the release notes for Subversion. Was this an accident or did
I miss something?

Thanks!
-- 
Douglas William Thrift

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Committer needed: update lang/J

[Kurt Jaeger]

Hi!

> I have a pending patch to update lang/J to the latest version. The updated
> version seems to also remove some problematic code that makes the package
> for 10.3 fail to build currently.
> 
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227395

Committed. Please try to find links to release notes or changelogs
for the next updates. Without those, it's difficult to understand
what happened.

-- 
p...@opsec.eu+49 171 31013722 years to go !
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Conflicts due to renamed KDE4 ports

[Tijl Coosemans]

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.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Conflicts due to renamed KDE4 ports

[Tobias C. Berner]

On 17 April 2018 at 14:00, Andriy Gapon  wrote:

> On 17/04/2018 10:24, Adriaan de Groot wrote:
> > 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 . That's the KDE4 version. Now there is port -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  are returning, without a suffix, to mean "the
> latest-and-greatest-
> > version-of-". This is consistent with other ports which have a
> ,
> > sometimes a -devel for upcoming things, and a - 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: -kde4 (and in the far future,
> -kf5) for
> > versions of the software based on an older stack, and  for the
> current
> > one. But the pain of getting from the mess to something better organized
> has
> > to happen at some point.
>
> Moin moin

I am just curious why not have explicit -kde4 and -kde5.
>
I think that qt sets a good example and there is no confusion and no
> migration
>
Short answer: Because there is no kde5

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.
This is not a new thing, it's just a lot in one go, I agree, and I'm sorry
for the inconvenience. However, let's not make a problem, that could
essentially
be solved by a pkg-delete followed by a pkg-add too complicated :)

I'll try to create a shell script to rewire the pkg's automatically to the
new origin...


mfg Tobias


pain in the future when 6 appears.
>
> --
> Andriy Gapon
>
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Conflicts due to renamed KDE4 ports

[Tijl Coosemans]

On Tue, 17 Apr 2018 00:42:48 +0200 Adriaan de Groot  wrote:
> [where did this discussion take place, earlier? this is the first I've seen 
> it]
> 
> 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 . That's the KDE4 version. Now there is port -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  are returning, without a suffix, to mean "the latest-and-greatest-
> version-of-". This is consistent with other ports which have a , 
> sometimes a -devel for upcoming things, and a - 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: -kde4 (and in the far future, -kf5) 
> for 
> versions of the software based on an older stack, and  for the current 
> one. But the pain of getting from the mess to something better organized has 
> to happen at some point.

What happens when you run pkg upgrade on a 6 months old installation of KDE4?
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

FreeBSD ports you maintain which are out of date

[portscout]

Dear port maintainer,

The portscout new distfile checker has detected that one or more of your
ports appears to be out of date. Please take the opportunity to check
each of the ports listed below, and if possible and appropriate,
submit/commit an update. If any ports have already been updated, you can
safely ignore the entry.

You will not be e-mailed again for any of the port/version combinations
below.

Full details can be found at the following URL:
http://portscout.freebsd.org/po...@freebsd.org.html


Port| Current version | New version
+-+
biology/gff2ps  | 0.98d   | 0.98l
+-+
biology/tinker  | 7.1.3   | 8.4.4
+-+


If any of the above results are invalid, please check the following page
for details on how to improve portscout's detection and selection of
distfiles on a per-port basis:

http://portscout.freebsd.org/info/portscout-portconfig.txt

Thanks.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Conflicts due to renamed KDE4 ports

[Adriaan de Groot]

[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 . That's the KDE4 version. Now there is port -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  are returning, without a suffix, to mean "the latest-and-greatest-
version-of-". This is consistent with other ports which have a , 
sometimes a -devel for upcoming things, and a - 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: -kde4 (and in the far future, -kf5) for 
versions of the software based on an older stack, and  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  wrote:
> > 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.

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 

Re: Conflicts due to renamed KDE4 ports

[Stefan Esser]

Am 17.04.18 um 00:42 schrieb Adriaan de Groot:
> [where did this discussion take place, earlier? this is the first I've seen 
> it]

Hi Adrian,

I did not see this being discussed before, just my posts that explain, why
portmaster cannopt deal with the simultanous renaming of ports and packages
(since it does not recognize the old version to conflict before trying to
install the renamed port as a dependency - that was when there were MOVED
entries, but portmaster had no logic to lookup by new origin to find the old
one and I found it hard to implement a work-around without a complete rewrite
of portmaster, which I'm working on for many weeks right now ...)

My interest in this issue is as the maintainer of portmaster. I can fix my
installed packages by changing the origin woth "pkg set -o" and then have
portmaster see the "link" between old and renamed origins and package names.

But without such a manual fixup of the pkg registry, portmaster will fail
on these ports (abort execution if any of the affected KDE4 ports is part
of the work list) and thus it appears to be a portmaster bug.

So, I'm looking at this issue not as KDE user, but as portmaster maintainer.

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

Yes, and the least I had expected was an entry in UPDATING, with commands to
execute on such a system to migrate to a state as if it had been installed
after the renaming of the KDE4 ports and packages, e.g.:

Execute the following commands to migrate your installed KDE4 packages to make
them consistent with the renamed KDE4 ports:

  pkg set -y -o databases/akonadi:databases/akonadi-kde4 -g "akonadi-1.*"
  pkg set -y -o graphics/okular:graphics/okular-kde4 -g "okular-4.*
  ...

As far as I'm concerned, it is not required that the package names are
adjusted, since that will correctly happen, if the registered port origins
are pointing at the locations used in DEPENDS entries.

BTW: Since akonadi-1.* and akonadi-17.* conflict with each other, it is not
possible to install any KF5 port that depends on akonadi in parallel to any
KDE4 port that depends on akonadi-kde4. I have not checked whether this
prevents parallel installation of the KDE4 and KDE5 desktops, but it will
cause further problems, if there are any installed ports that need the old
version and any KF5 ports that have (direct or indirect) dependencies on
the akonadi-17.*, but it is likely to cause portmaster to fail, since it
cannot know how to deal with that conflict. (Such conflicts are typically
for ports like samba for which many versions exist, that are mostly
inter-changeable from the point of view of view of ports that just require
any samba server version to be installed. The typical logic in portmaster
is to keep such conflicting versions, instead of replacing them with the
exact version specified as a dependency., but that will make portmaster
try to build KF5 programs with akonadi-kde4, if that happens to be installed
at that time.)

> For single applications, the migration looks similar: you had, around january 
> 2018, port . That's the KDE4 version. Now there is port -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  are returning, without a suffix, to mean "the latest-and-greatest-
> version-of-". This is consistent with other ports which have a , 
> sometimes a -devel for upcoming things, and a - for older 
> versions if you have specific dependencies on old versions.

Yes, and there's nothing wrong with this approach in general, IMHO. But in
the case of a framework with  many inter-dependent packages as is the case
for KDE, such a renaming has a large chance of introducing inconsistencies.

As I said before: If the KDE4 ports had not been changed with regard to port
origin and package name at the time, port management tools had a chance to
detect the connection between old and new names. But with both changed and
no MOVED entries (because of the new KDE5 versions of the ports), there is
no basis for a decision (but the conflict will be detected and has to be
manually fixed by deleting the old version to allow the renamed version to
install).

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

The scheme looks 

Committer needed: update lang/J

[João Neves]

Hi,

I have a pending patch to update lang/J to the latest version. The updated
version seems to also remove some problematic code that makes the package
for 10.3 fail to build currently.

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227395

If anyone has some extra cycles to take a look it would be very appreciated.

Thanks,

--
João Neves
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"