Date: Sat, 14 Feb 2015 12:44:43 -0600 From: Andrew Berg <aberg010@my.hennepintech.edu> To: <freebsd-questions@freebsd.org> Subject: Re: Ports/Packages and release engineering Message-ID: <54DF979B.4050301@my.hennepintech.edu> In-Reply-To: <54DF89BE.6010005@complete.org> References: <54DF89BE.6010005@complete.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2015.02.14 11:45, John Goerzen wrote:
> So, it looks to me that ports is essentially always a -CURRENT tree. I
> don't see any reference in the handbook to selecting different branches
> of ports, or different branches that might happen to match different
> RELEASE versions.
It's similar to -CURRENT, I suppose. There are quarterly branches where big
changes are put off until the next quarter, but security updates are still applied.
There are actually tags for each release, though they are not generally useful
except as reference points. Ports are made to work with all supported releases.
> How, then, is quality maintained within the ports?
> Is it just luck of the draw on when a local update happens that it gets
> a version that didn't have a silly bug that got corrected a day later,
> or how do ports get tested before being released to everyone?
Generally, maintainers are responsible for their individual ports. Larger
changes (especially ones that affect significant chunks of the tree) are
reviewed and approved before being committed. Mistakes and oversights do
happen, even with several people looking at the patch.
> One thing I know from Debian is that there we often have "transitions"
> from Debian's unstable (roughly -CURRENT) to testing (roughly -STABLE)
> when certain groups of packages have to be transitioned in sync in order
> to avoid breakage. This might be things relating to KDE (such as
> Digikam), or another example is Haskell, where new versions of the
> compiler ghc introduce a different ABI requiring all the Haskell module
> packages to be rebuilt. There are plenty of examples, though. How are
> these handled in FreeBSD?
Things are kept in sync with upstream as far as major versions go. For example,
Python 2.7, 3.3, and 3.4 are all still supported upstream, so there are
individual ports for each, and you don't really need to worry about your
default Python suddenly being upgraded from 2.7 to 3.4 unless you explicitly
make it so. This goes for anything where multiple versions are supported
upstream - gcc, clang, Apache, perl, etc..
As I said above, ports are expected to work on all supported versions of
FreeBSD. It's not "version X of KDE works on 8 and version Y works on 9 and
version Z works on 10", it's "version Z works on 8, 9, and 10".
>
> When packages are updated, what happens to their config files and rc.d
> scripts? Are files in /usr/local/etc, /etc, {/usr/local,}/etc/rc.d
> never modified automatically, or is the administrator prompted on what
> to do (as in Debian)? If they are never modified automatically, how
> does a person know what changes to make after an update?
rc scripts shouldn't be modified by the user. Configuration files aren't
tracked by ports because it's silly to push a configuration on users. Ports
*should* come with example configuration files, and if there are any changes to
be made to configuration that aren't obvious (a major version change should
signal you to go look at upstream docs, but sometimes upstream changes things
like that between major releases for no good reason), then maintainers *should*
include a message. Again, maintainers are responsible for their ports.
> This brings me to the question of how the ports/packages relate to the
> base system. A couple of things surprised me in researching this
> question: the first being the comment in the Handbook to reinstall the
> entire ports/packages system after a base system upgrade to a new major
> version, due to ABI incompatibilities. I would have thought backward
> ABI compatibility would be a pretty important design goal in FreeBSD.
It is only a goal between minor versions. New major versions are free to break
lots of things, but new minor versions must not break anything. This is the
whole point of having separate release branches.
> The other thing was that ports are only tested against -CURRENT and
> -STABLE, therefore implying that even the current -RELEASE may not have
> working ports (let alone even an LTS -RELEASE). That leaves me
> concerned about the long-term viability of managing FreeBSD systems, but
> also wondering if I'm missing out on some important bit of information here.
Ports are almost always tested against release versions, and having ports work
on releases is far, far more important than having them work on -STABLE or
-CURRENT. -CURRENT isn't even considered "supported" by the ports tree, and
having things work on it is best effort since it can easily have breaking
changes with little more than a post to the current mailing list as warning.
> Speaking of which, when the base system is upgraded, how are
> administrator customizations in /etc and related configuration locations
> preserved? (Same question as with the ports updates above.)
Files are merged, and you decide how to handle changes.
> Another small question: I ran something like "pkg install xserver-xorg
> digikam vim screen bash" the other day in my FreeBSD test VM. I
> discovered quite a bit of information was printed out at the end from
> various packages, which scrolled off the screen. Is there a way to
> re-display all that information? It seems if it's important enough to
> display, it's important enough to display long enough to read ;-)
portmaster does some things to make sure that all the pkg-messages are
displayed at the end and piped into less if necessary. I suppose you could make
a feature request for pkg to do that. I suspect many have not found it that
much of an issue because they can use tmux or some other console to scroll up.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?54DF979B.4050301>