[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: pkgsrc dev
-----BEGIN PGP SIGNED MESSAGE-----
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.
>> 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
> 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
> 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,
> 9. most of pkgsrc is designed to build as an ordinary user.
> Privileges will be raised, and credentials obtained, as and when
> 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
> 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.
> Best, Alistair
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with undefined - http://www.enigmail.net/
-----END PGP SIGNATURE-----
Main Index |
Thread Index |