Re: pkgsrc dev

[Chris Petrik <cpet%sdf.org@localhost>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Do you have a means of using github or other services that host src's
that don't have a released tarbal?

On 12/3/2012 8:11 PM, Alistair Crooks wrote:
> 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
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQEcBAEBAgAGBQJQvWXDAAoJEAGnn5Nn8qWUDbsIAJdG3bkHVzfQkiIV/vpbZuYT
IqPBmQi0TQ9tDE4eGCYmHcAvQW9DVE97gR22ZaWw/VCQXUQ+l/w3LlTwUMZoxqdx
zAY9vH0X0IheqxFGX92mqucmEULij86Z3qzqdwZ56KLSU1QdkVSs4oScpaUrS7W/
VdyFX55UthyueKHz26uN6EidII2IhoymohiodXbiiDqzIaLSb6vWD3i7quHr601g
XHLcKIGzffDKGCRzPE+8ZFeSAPKQq9KzsBYODbsqXIB82tvQGrqKX/lynDyXSojy
b2xsqTs1HObgTwSN6DFGZkhwuutYNt3C8vGDcAU4TqKrvUEY0Byg4YakCpdF8Fc=
=I8JV
-----END PGP SIGNATURE-----