I though to start a separate thread, the previous one will continue to exists to discuss about the builder machine and software, this one is meant to discuss about the software we want make available, the software that we don't want and in general issues related to software selection.

An average Linux distro, at least those who provide a binary repository are usually bound to a single version of each packaged software, with exceptions:
- sometimes both the current and previous gcc suite is provided
- sometimes other software are provided in two versions, firefox vs. firefox-esr,
- libreoffice vs. openoffice
- etc.

This approach has some benefit, in that overall the packages are mostly constantly keep up to date with an "harmonyzed" set of libs and dependencies.

FreeBSD port system is much wider (too much) and it include a lot of "duplicates":
- the (nearly) whole gcc series
- the (nearly) whole clang series

Now, it is my understanding that some software may require a specifc C/C++ compiler to build, so there is not much we can do about other than let it be pulled in as a build-dependency.

However I wonder if we should really provide all that "not up to date" packages to flow in our repos ....
It is a question I'm asking to myself and to you.

Libreoffice vs. OpenOffice.org
Do we provide both suites ? (I would say yes, if it was not because the openoffice ones are problemati to build),
your opnion will be appreaciated.

Another good example is what was found to be the biggest package (5 GB):
It turned out it is an optional component of a chess game, a database table aimed to help to predict the outcome of chess moves.

I would say that not all GhostBSD users are interested in chess games, among them only a few will be probably interested to that specific chess game (crafty) among many others, and among those only very few will be interested in using that database table (which also look outdated, being from 2007 or so).

Do we really want to provide such monster package for the benefit of probably less then 0.01% of gbsd users?
(out of curiosity, the next-level database table is probably going to be on the order of mangnitude of a Terabyte and I'm guessing a really passionate of chess is going to get that version, not the inferior one).
https://chessprogramming.wikispaces.com ... Tablebases

Of gcc and clang we could only keep the dependency and the latest.

OpenOffice.org development on my understanding is gonna stop, I might be wrong, I use LibreOffice, only because I have no better option.

For the Chess Game database is not needed and if anyone want it they can compile it.

I agree with you, that imply we are going to build a list of packages to be built: (or a list of packages to be excluded) or somthing similar.

The problem with a package list is that we might miss some new package sometimes ...
A list of excluded look a little better, but is not directly accepted from synth, therefore we need to build a tool to diff a complete list against our "no-build-list"., should not be to difficult.

btw, the "crafty" chess game can remain, the optional 5GB database table can be left out.

Agreed also to leave out opeoffice (btw, dragonfly did the same), eventually we will re-evaluate that upon user request, if any,

I also agree that it doesn't make sense to provide each and every compiler version in binary form - and that chess database... Well, chances are that nobody is ever going to miss it.

About OpenOffice: This is actually a pretty sad thing. I really wish, Oracle had donated it to the Apache foundation before ruining it... It's not officially dead, yet, but AF has stated that they were thinking about burying it. The last thing that I read was however that it was slowly getting traction again. Don't know if that's true, though. One thing's fore sure however: LibreOffice is where active development is being done. OpenOffice is kind of rotten by now - which is a shame since it has a much better license (Apache vs. GPL). But it's almost certainly not worth supplying both. I'd vote against OpenOffice in this case.

We could effectively drop all packages depending on old compilers and thus get rid of them:

https://wiki.freebsd.org/ObsoleteLLVMVersions

should we ?

ASX wrote:We could effectively drop all packages depending on old compilers and thus get rid of them:

https://wiki.freebsd.org/ObsoleteLLVMVersions

should we ?

I'd say: Let's drop them and wait until somebody complains. The pkg repo will be quite big anyways and it's certainly not a bad idea to do some housekeeping. We can decide to build some of them if somebody actually needs them.