quarterly vs. latest

[ericbsd]

A question, is this for a forum post or the website?

[ericbsd]

There is something missing in the text "The reason why 11.0 is delayed".

[kraileth]

A question, is this for a forum post or the website?

Website, I guess.

There is something missing in the text "The reason why 11.0 is delayed".

Right, I'll add that again:

Upcoming GhostBSD 11.0: New pkg repositories

The next major version of GhostBSD will feature our own package repositories instead of continuing to use those from FreeBSD. This is the major reason for the delay of the release.

There are several reasons for creating our own repositories:

1) FreeBSD is geared more towards servers while GhostBSD targets the desktop. Maintaining our own repositories gives us more control and allows us to set buildtime options differently.

2) It allows us to update GhostBSD specific applications (e.g. the update station) via pkg, too.

3) Creating an additional repository would lead to technical problems and quite possibly break applications (packages from two different repositories could depend on different versions of the same dependency package).

A separate bild server was rented and will be building updated packages weekly. We found using Synth to build ports fits us better than Poudriere (thanks to J.R. Marino for that nice program!).

Initially the plan was to go with the "quaterly" ports branch from FreeBSD. Unfortunately the last quaterly update broke X11 for a lot of users and thus proved not to meet our requirements at all.

GhostBSD will provide packages for i386 and amd64. For both architectures there will be 3 public repositories:

"latest", which matches FreeBSD's ports + GhostBSD ports + changed options and perhaps patches. The devs will run this and advanced users who are willing to test are welcome, too.
"current", which will be the default repository for GhostBSD.
"previous", which keeps the previous packages available after "current" was updated.

By using "latest" we hope to catch problems before broken packages go into "current". If something we don't use breaks, there's "previous" as a fallback repo.

For users who like packages but need to build some ports themselves to change options, we will provide the patched ports tree that we build packages from. It will be made able it via git.

[ASX]

please remove this:

It will be made able it via git.

it has not been discussed/decided at all, still not sure how we will make it available.

For your info, there could be two ways to generate our source tree:

a) forking freebsd ports tree and patching that
(so far we though that it would require a lot of work, probably too much)

b) building a small tree from our own ports (update station, ...)
and merging it with freebsd ports by using a few scripts to automate the process.

In the latter case, being the source tree a 'product' obtained from two live src tree, it will be a read-only repo, without versioning ... most likely will be shared via rsync ...

I have already opened a thread to discuss about the source tree.

[kraileth]

please remove this:

It will be made able it via git.

it has not been discussed/decided at all, still not sure how we will make it available.

For your info, there could be two ways to generate our source tree:

a) forking freebsd ports tree and patching that
(so far we though that it would require a lot of work, probably too much)

b) building a small tree from our own ports (update station, ...)
and merging it with freebsd ports by using a few scripts to automate the process.

In the latter case, being the source tree a 'product' obtained from two live src tree, it will be a read-only repo, without versioning ... most likely will be shared via rsync ...

I have already opened a thread to discuss about the source tree.

Ah, ok. Is the announcement meant to be published before the final decision on this matter is made? In that case I'd simply remove the git sentence and we can state later which way to get hold of the ports tree.

[ASX]

Ah, ok. Is the announcement meant to be published before the final decision on this matter is made?

Yes, because it is also an explanation about the release delay.

In that case I'd simply remove the git sentence and we can state later which way to get hold of the ports tree.

yep.

[ericbsd]

Look good enough.