Ports/Packages and release engineering

[John Goerzen]

Matthew Seaman <m.seaman <at> infracaninophile.co.uk> writes:

> 
> On 14/02/2015 17:45, John Goerzen wrote:

> Configuration files are *not* owned by ports per-se, so they aren't
> necessarily removed or modified when a port is deleted or updated.
> Instead the port owns various sample configuration files, which
> generally have the same name as the actual config with '.sample'
> appended (other naming variations exist, but '.sample' is by far the
> commonest.)  These the port will replace at will.  When a port is
> installed the first time then the sample config file is copied to the
> real config file name.  When the port is removed or upgraded, then the
> config file is removed if and only if it is identical to the sample file.
> 
> There isn't a capacity for doing a three-way merge in the ports at the
> moment, so if the upstream has made incompatible changes to the config
> file format the administrator will have to merge those manually.  This
> is fortunately a fairly rare event.  3-way merge capability has been
> added to pkg(8) but that capability hasn't been applied to the ports yet.

Matthew, thank you for your very helpful reply.  A few small outstanding
questions:

I actually expect to use pkg(8) rather than ports almost all of the time. 
So it sounds nice that pkg(8) can do this, but I am confused about the
relation between ports and pkg.  I see some rather contradictory information
out there, and wonder if this changed in FreeBSD 9 or 10?  I see some people
saying that a person always needs to tell the ports system to register with
pkg, but then I don't see anything in the Handbook saying to do that these days.

So if a port only supplies a .sample, on what basis would pkg do a 3-way
merge, since nobody is likely to modify .sample directly?

> Reinstalling all your ports on a major version upgrade is still a
> requirement, yes.  But it is something that may not remain so for a
> great deal of time longer, given the advent of symbol versioning in the
> base system shared libraries.  While you can still *run* a port
> installed for, say, 9.3-RELEASE once you've upgraded to 10.1-RELEASE,
> until everything in the base system has appropriate symbol versioning
> applied you'll very quickly get into a pickle if you try and update some
> ports selectively: effectively you would end up with one binary trying
> to dynamically link against two or more different versions of the same
> shared library: something that always ends in tears.

Ah.  OK.  So is there really that much churn in base system libraries?  It's
not necessarily an issue for me, but just a surprise; I'm used to systems
where most binaries that are a decade old still work fine on modern systems.

Thanks again,

John