private ports and pkgs versioning

Tue Oct 18 07:49:18 UTC 2016

On 18/10/2016 06:58, Julian Elischer wrote:
> Is there a standard way of naming a pkg that is locally compiled (maybe
> with a different set of options, or a local patch) so that it doesn't
> get confused with generic ports that are from freeBSD.org?

If you're not making local changes to the port, it's usual that you'ld
just call your locally compiled package the same as the generic ports.

If you're creating a new local port, or a variant on one of the standard
ports, then you should use a distinct name.  Using PKGNAMEPREFIX is
probably the simplest way to do that, but obviously that may cause
problems where PKGNAMEPREFIX is already in use -- eg. any python or perl
or apache24 port.  Similarly there's a PKGNAMESUFFIX but similar caveats
apply.  If you go down this route, you'ld also have to chase any
dependency lines in ports you want to use that depend on your local
variant, so you might end up with a quite significantly modified ports tree.

> I want to use mostly standard pkgs but need to compile a few myself
> (this can't be an uncommon requirement).

The usual way of handling this is to build your own repo using poudriere
(or otherwise), and add this to /usr/local/etc/pkg/repos/foo.conf at
higher priority than the generic FreeBSD repos.  pkg(8) will generally
prefer packages from higher priority repos.

Note that building a repo like this with poudriere will include not just
the packages you're interested in but also all of their build- and run-
time dependencies.

> How can I name my variant pkgs so the the pkg program (and ports) can
> still know that it is a satisfactory supplier of prerequisite components?
> 
> e.g.  if a pkg wants a specific rev of libxml2 how much does it use of
> the name libxml2-2.9.2_2 ?

pkg(8) doesn't have a mechanism for only looking for one specific
version of a package -- it's always going to look for the most recent
version of any package.

You could take a local copy of the port and add a PORTEPOCH, but
otherwise freeze the port at your preferred version.  The PORTEPOCH will
automatically make your copy a higher version that what's available from
the general ports tree, so pkg(8) should prefer it.

Note that doing this will foil the mechanisms used by pkg-audit(8) to
warn you of any vulnerabilities in libxml2

> Can (should) I add stuff after the '_'?  If I do will it still recognise
> my pkg file and if I do are there any rules regarding *WHAT* I can put
> there.

Package versions look like this:

    aa.aa.aa_b,c

where aa.aa.aa is the upstream version number, or derived from it.  'b'
is the PORTREVISION which is an integer and omitted if zero. 'c' is the
PORTEPOCH -- again an integer and ommitted when zero.  PORTREVISION is
reset to zero whenever the upstream version changes, but PORTEPOCH if
used is there for ever and much be monotonically increasing.  When
comparing two versions, the PORTEPOCH has the greatest significance,
then the upstream version, then the PORTREVISION.

Only the upstream version can contain non-digits -- '.' as a field
separator and single alpha characters in some fields.  The ports will
take the upstream DISTVERSION and automatically produce a PORTVERSION
modified according to these rules.  The point of this transformation is
to ensure that versions sort in a useful way.

So, for example, the lang/perl5.22 port contains:

PORTNAME=       perl
DISTVERSION=    ${PERL_VERSION}-RC4
PORTREVISION=   0

where:

% make -V PERL_VERSION
5.22.3

and this results in a PKGNAME of:

% pkg info -x perl5
perl5-5.22.3.r4

> lastly is there somewhere I should be looking to read all this
> information rather than pestering the mailing list?

The Porter's Handbook contains a lot of this stuff, and there is a lot
of documentation in the comments in /usr/ports/Mk/bsd.port.mk and other
Makefiles in that directory.

The rules on package version numbers are expressed in code in
pkg-version(8) -- here:

https://github.com/freebsd/pkg/blob/master/libpkg/pkg_version.c

> What I'd like to have is my own depot with something like:
> 
> ===
> 
> libsmi-0.4.8_1.txz
> libxcb-1.11.1.txz
> libxml2-2.9.2_2-mumble.3.txz
> lsof-4.88,8.txz
> lsof-4.90.b,8.txz
> m4-1.4.17_1,1.txz
> 
> ===
> 
> where 'mumble.3' is a locally defined addition, but all the rest of the
> pkgs are straight from pkg.freebsd.org, (or at least compile in default
> form).

That 2.9.2_2-mumble.3 version string doesn't play by the rules.  For a
start, the system will consider the version number to be everything
after the *last* '-' character in the pkg name, not counting any .txz or
similar suffix.  So your version here is 'mumble.3'  which is still
illegal according to the rules.

It also considered everything before the last '-' character to be the
package name so instead of 'libxml2' you've now got 'libxml2-2.9.2_2'
and that won't match properly when trying to resolve dependencies.

You'ld be better off aiming for a version like this:

   libxml2-2.9.2.m3_2.txz

which you could achieve by directly modifying PORTVERSION or DISTVERSION
in your private copy of the port.

Or add your own PORTEPOCH to get

   libxml2-2.9.2,1.txz

The former will not sort as a higher version should the upstream version
get bumped, but the latter will.  Use 'pkg version -t' to test where the
modified version would sorts in relation to the regular one.

> This "kind-of" works, but the rules of play are not defined anyhere I
> have read, so I don't know if it's going to suddenly fail one day.
> 
> Also it's be really nice if there were a variable I could set to
> "mumble.3" so that I don't have to do a manual rename, because between
> the time that the package is made and it is renamed there is a
> 'misnamed' package sitting around acting as a potential source of
> confusion.

Yes, there is a lot of useful stuff in the ports tree to support local
ports or even whole local categories of ports.  I can't recall now how I
learned about all this stuff -- it may well have been just be a
combination of reading Makefiles and hints dropped on mailing lists.  I
cannot recall a document describing this stuff anywhere.

	Cheers,

	Matthew

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 931 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20161018/e4dcb9ff/attachment.sig>