Re: pkgsrc dev

[Alistair Crooks <agc%pkgsrc.org@localhost>]

On Mon, Dec 03, 2012 at 06:52:34PM -0600, Chris Petrik wrote:
> I am new to this as coming from FreeBSD's ports.

Welcome!
 
> I am wanting to update a port but I don't have an idea on the pkgsrc
> infrastructure a link or input would be greatly appreciated.

The infrastructure is similar to the ports tree, but a number of
things are done differently.  I'll attempt to outline some of them
here, but I'm sure I'll miss some. If anything's unclear, please
ask.

1.  pkgsrc itself is location independent, so you can have multiple
trees checked out in different places, in different states, and
everything should DTRT.

2. pkgsrc uses a mk.conf file instead of a make.conf file; its
location depends on the operating system being used.

3.  No UIDs or GIDs file - users are created according to rules in the
pkgsrc Makefile anyway.

4.  When creating packaing lists, use "make print-PLIST" - it will do
the heavy lifting for you.  Only case where you may have to fixup
things is when options are involved.

5. pkgsrc bootstraps itself on every platform except NetBSD, so
it is self-sufficient.

6. the pkgsrc guide (pkgsrc/doc/pkgsrc.*) is useful for finding things
out. It's split into two parts, one for the user, and one for the ones
who want to get under the hood.

7.  pkgsrc is designed to build according to what is wanted, not
what's installed on a machine already - it does this through a
mechanism known as buildlink.  Args are massaged in the build process,
so that it doesn't matter if (on NetBSD, for example) ncurses is
installed, the package will only link with ncurses if some
ncurses-specific functionality is needed.

8.  when building from source, pkgsrc installs files into a staging
area, a binary package is made, and the binary package is then
installed.  The binary package can be used elsewhere with binary
package managers such as pkgin and nih.  It makes it much less drastic
when adding and deleting packages, overwriting files, etc.

9.  most of pkgsrc is designed to build as an ordinary user. 
Privileges will be raised, and credentials obtained, as and when
necessary.

10. pkgsrc keeps build infrastructure in the binary packages, so it's
possible to see what patches are in a binarey package, and what options
a package was built with.

11.  pkg_info and the pkg_* tools do not require version numbers. 
Hence I can easily get info on packages by saying pkg_info vim, or
pkg_info vile, or whatever.  To find out information from a binary
package, a slash must appear in the file name.  This is to avoid the
POLS when using pkg_info in a directory with a binary package in it.

12. pkgsrc version numbers can be checked relative to one another.
pkg_info vile>=9.7 will return information on any vile package matching
a version greater than or equal to 9.7. Rules for this are given in the
pkg_info(1) manual page. This is primarily used for finding packages
which have security vulnerabilities. Don't worry, you'll be nagged
about this one - or look for "audit-packages", the high-level interface
to it.

13. There is no "Security report" when installing packages (I'm not
convinced of the use of this thing in FreeBSD's ports - it seems to
be very much the same thing; no useful information in there).

14.  In general, pkgsrc has fewer categories than FreeBSD
(intentionally) - different language versions are placed side-by-side
with original packages.  Packages are grouped by function, not by
japanese, or korean etc.  pkgsrc-wip on sourceforge is a staging area
for packages which are not yet ready for pkgsrc, and also a staging
ground for pkgsrc developers who are not quite ready for pkgsrc yet. 
pkgsrc packages can go both ways - to and from pkgsrc-wip.

15. although pkgsrc has fewer packages, it runs on many more platforms.
If you're making changes to pkgsrc entries, please be aware that
others may have to live with your work on different platforms, so make
sure that, where possible, your changes are based on features, not
platforms. pkgsrc itself has an abstraction layer like that, so if
you're bringing up a new platform with pkgsrc, relatively few things
need to be modified, and they are grouped in the same place.

16. pkgsrc has quarterly releases - they are branched every quarter, which
aims to strike a balance between functionality from new releases and security
fixes, and lack of bleeding edge churn. This release strategy is decoupled
from OS release strategies. Intentionally :-).

The list above is probably enough to be going on with for now.  There
is a pksrc entry linter called pkglint, chroot sandboxes to build a
few or many packages are easy to create and destroy, and full bulk
builds are done by a number of people, and the tools are all in pkgsrc
too.

Enjoy!

Best,
Alistair