Ports/Packages and release engineering

[Matthew Seaman]

On 14/02/2015 23:20, John Goerzen wrote:
> Matthew Seaman <m.seaman <at> infracaninophile.co.uk> writes:
> 
>>
>> On 14/02/2015 17:45, John Goerzen wrote:

> 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.

pkg(8) is the only game in town now, and has been since last april
(IIRC).  All supported versions of FreeBSD use pkg(8). There's a lot of
historical information floating around from the transition period when
lots of people were still running pkg_tools based systems and many of
them were needing to convert.  You'ld have to be running something
pretty seriously out of date to still be in that position today though.

As for ports and pkg: it's easy really.

   ports are a set of instructions for building 3rd party software

   pkg(8) is a tool for managing collections of files, commonly used
   for handling the results of ports compilations.

All the binary packages currently available are the results of ports
compilations, be that ones done on the central package building systems,
or ones done locally on an individual system via tools like
portmaster(1) or portmanager(1).

> 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?

At the moment, pkg(8) doesn't do any 3-way merging.  That's something
that is currently under development.

> 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.

The promise is that a binary compiled on the earliest release from any
major branch will be forward compatible with any subsequent releases
from that same major branch.  (So something compiled under 9.0 will work
on 9.3, but something compiled on 9.3 will not necessarily work on 9.0).

Yes, there are quite likely to be incompatible changes in the standard
library ABIs between major versions.  Something as simple as changing
the size of a struct can break the ABI, even though it still maintains
the same API and exactly the same soure code, once recompiled, will work
just fine.   Symbol versioning allows a single shlib to provide older
variants of an ABI as well as the latest one, which means you can get
both forwards and backwards compatibility.  I don't think that the
symbol versionning support is comprehensive enough yet, or well tested
enough yet that the advice to re-install everything on a major upgrade
will be changed any time soon.

	Cheers,

	Matthew

-- 
Dr Matthew J Seaman MA, D.Phil.
PGP: http://www.infracaninophile.co.uk/pgpkey


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 971 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20150215/79f5ea93/attachment.sig>