Section 15.4.1 of the OpenBSD FAQ states that it is possible to use -release ports/packages on a -stable system. Is the opposite also officially supported by the project? I am currently running OpenBSD 4.6 with errata patches on an old IBM ThinkPad A20m laptop, and I want to keep my compile time to a minimum by not needing to track the -stable base while still having security updates for certain software.

Speaking of -stable ports, are there also -stable packages available for the i386 architecture? I saw a comment on the OpenBSD Journal stating there is, but I have been unable to confirm it.

Once the -release branch is tagged, no changes are further made to this branch. To anticipate what changes might be forthcoming to -stable packages/ports is impossible to make, so to make a blanket pronouncement stating that -stable packages/ports can run as expected on -release is likely never to be made.

Note that -release + all released patches is very closely equivalent to -stable. Traditionally, there are no library changes made from -release to -stable. Most likely, -stable packages/ports will work on a fully patched -release system, but this is conjecture on my part, & I highly doubt that anything will ever be said officially to remove the existing ambiguity.

The project wants to focus on new development in -current. This is why -stable tends to be short shrifted.

Quote:

...are there also -stable packages available for the i386 architecture?

Once the -release branch is tagged, no changes are further made to this branch. To anticipate what changes might be forthcoming to -stable packages/ports is impossible to make, so to make a blanket pronouncement stating that -stable packages/ports can run as expected on -release is likely never to be made.

Note that -release + all released patches is very closely equivalent to -stable. Traditionally, there are no library changes made from -release to -stable. Most likely, -stable packages/ports will work on a fully patched -release system, but this is conjecture on my part, & I highly doubt that anything will ever be said officially to remove the existing ambiguity.

The project wants to focus on new development in -current. This is why -stable tends to be short shrifted.

Ah, that makes a lot of sense. In that case, I think I will stick with the -release packages/ports tree, since I am new to OpenBSD and do not want to run the risk of breaking anything.

Quote:

Originally Posted by ocicat

No evidence is seen on the ftp sites at this time.

Hmm, either the -stable package plan must have been abandoned, or there was never one in the first place. I am guessing that the latter is the case, since the only reference to packages I have ever seen was in that OBSD Journal comment.

Concerning the -release packages, how much of a risk do you think I am taking, in terms of security, by running (up to) six-month-old software? I was always taught to apply security updates whenever they appear, but by using packages with my -release base as the OpenBSD developers recommend, that does not seem to be possible. OpenBSD is a very security-conscious group, so do I have anything to be concerned about?

Concerning the -release packages, how much of a risk do you think I am taking, in terms of security, by running (up to) six-month-old software?

It will depend on the specific software, and the dependency chain.

If you follow -stable (or the errata patchs, which is not quite but nearly the same thing), you will have a system that has no library changes, no functionality changes, but with patches for stability or security to the OS added.

If there is an update to a particular 3rd party package you need, and a -stable package is not available, you can either ask the associated port maintainer to work up a -stable package for you, or, develop it yourself.

In general, any update to software that adds functionality will also add risk of additional stability or security trouble. So-called "bug fix" releases that do not add any new functions are, generally, safer than those that don't. But each case is a judgement call, and an understanding of the risks is required.