Question

+

24.6.

+

What does + ${MASTER_SITE_SOURCEFORGE:=package/} mean? I + don't understand the := inside + it.

Answer 1

For optimization reasons, some variables are only + available in the “wrapper” phase and later. To + “simulate” the wrapper phase, append + PKG_PHASE=wrapper to the above + command.

Answer 2

The := is not really an + assignment operator, although it looks like it. + Instead, it is a degenerate form of + ${LIST:old_string=new_string}, + which is documented in the make(1) man page and which is + commonly used in the form ${SRCS:.c=.o}. In the + case of MASTER_SITE_*, + old_string is the empty string and + new_string is + package/. That's where the + : and the = fall + together.

Answer 3

tech-pkg: This is a list for technical discussions related + to pkgsrc development, e.g. soliciting feedback for changes to + pkgsrc infrastructure, proposed new features, questions related + to porting pkgsrc to a new platform, advice for maintaining a + package, patches that affect many packages, help requests moved + from pkgsrc-users when an infrastructure bug is found, + etc.
pkgsrc-bugs: All bug reports in category "pkg" sent with + send-pr(1) appear here. Please do not report your bugs here + directly; use one of the other mailing + lists.

Answer 4

+

There are many places where you can find + documentation about pkgsrc:

+

The pkgsrc guide (this document) is a collection + of chapters that explain large parts of pkgsrc, but some + chapters tend to be outdated. Which ones they are is hard to + say.
On the mailing list archives (see https://mail-index.NetBSD.org/), you can find discussions + about certain features, announcements of new parts of the pkgsrc + infrastructure and sometimes even announcements that a certain + feature has been marked as obsolete. The benefit here is that + each message has a date appended to it.
Many of the files in the + mk/ directory start with a comment that + describes the purpose of the file and how it can be used by the + pkgsrc user and package authors. An easy way to find this + documentation is to run bmake + help.
The CVS log messages are a rich source of + information, but they tend to be highly abbreviated, especially + for actions that occur often. Some contain a detailed + description of what has changed, but they are geared towards the + other pkgsrc developers, not towards an average pkgsrc user. + They also only document changes, so if you + don't know what has been before, these messages may not be worth + too much to you.
Some parts of pkgsrc are only “implicitly + documented”, that is the documentation exists only in the + mind of the developer who wrote the code. To get this + information, use the cvs annotate command + to see who has written it and ask on the + tech-pkg mailing list, so that others can + find your questions later (see above). To be sure that the + developer in charge reads the mail, you may CC him or + her.

+

Answer 5

+

This is not really an FAQ yet, but here's the answer +anyway.

+

Run pkg_chk -N (from the + pkgtools/pkg_chk package). It + will tell you about newer versions of installed packages that are + available, but not yet updated in pkgsrc.
Browse pkgsrc/doc/TODO + — it contains a list of suggested new packages and a list of + cleanups and enhancements for pkgsrc that would be nice to + have.
Review packages for which review was requested on + the tech-pkg + mailing list.

+

MASTER_SITE_APACHE	MASTER_SITE_BACKUP
MASTER_SITE_CRATESIO	MASTER_SITE_CYGWIN
MASTER_SITE_DEBIAN	MASTER_SITE_FREEBSD
MASTER_SITE_FREEBSD_LOCAL	MASTER_SITE_GENTOO
MASTER_SITE_GITHUB	MASTER_SITE_GNOME
MASTER_SITE_GNU	MASTER_SITE_GNUSTEP
MASTER_SITE_HASKELL_HACKAGE	MASTER_SITE_IFARCHIVE
MASTER_SITE_KDE	MASTER_SITE_MOZILLA
MASTER_SITE_MOZILLA_ALL	MASTER_SITE_MYSQL
MASTER_SITE_NETLIB	MASTER_SITE_OPENBSD
MASTER_SITE_OPENOFFICE	MASTER_SITE_OSDN
MASTER_SITE_PERL_CPAN	MASTER_SITE_PGSQL
MASTER_SITE_PYPI	MASTER_SITE_RUBYGEMS
MASTER_SITE_R_CRAN	MASTER_SITE_SOURCEFORGE
MASTER_SITE_SUNSITE	MASTER_SITE_SUSE
MASTER_SITE_TEX_CTAN	MASTER_SITE_XCONTRIB
MASTER_SITE_XEMACS	MASTER_SITE_XORG

MASTER_SITE_APACHE	MASTER_SITE_BACKUP
MASTER_SITE_CRATESIO	MASTER_SITE_CYGWIN
MASTER_SITE_DEBIAN	MASTER_SITE_FREEBSD
MASTER_SITE_FREEBSD_LOCAL	MASTER_SITE_GENTOO
MASTER_SITE_GITHUB	MASTER_SITE_GNOME
MASTER_SITE_GNU	MASTER_SITE_GNUSTEP
MASTER_SITE_HASKELL_HACKAGE	MASTER_SITE_IFARCHIVE
MASTER_SITE_KDE	MASTER_SITE_MOZILLA
MASTER_SITE_MOZILLA_ALL	MASTER_SITE_MYSQL
MASTER_SITE_NETLIB	MASTER_SITE_OPENBSD
MASTER_SITE_OPENOFFICE	MASTER_SITE_OSDN
MASTER_SITE_PERL_CPAN	MASTER_SITE_PGSQL
MASTER_SITE_PYPI	MASTER_SITE_RUBYGEMS
MASTER_SITE_R_CRAN	MASTER_SITE_SOURCEFORGE
MASTER_SITE_SUNSITE	MASTER_SITE_SUSE
MASTER_SITE_TEX_CTAN	MASTER_SITE_XCONTRIB
MASTER_SITE_XEMACS	MASTER_SITE_XORG

If the package...	Then...
Installs OMF files under `share/omf`.	See Section 21.6.10, “Packages installing scrollkeeper/rarian data files”.
Installs icons under the + `share/icons/hicolor` hierarchy or updates + `share/icons/hicolor/icon-theme.cache`.	See Section 21.6.19, “Packages installing hicolor theme icons”.
Installs files under + `share/mime/packages`.	See Section 21.6.14, “Packages installing extensions to the MIME database”.
Installs `.desktop` files under + `share/applications` and these include MIME + information.	See Section 21.6.20, “Packages installing desktop files”.

If the package...	Then...
Installs OMF files under `share/omf`.	See Section 21.6.10, “Packages installing scrollkeeper/rarian data files”.
	For optimization reasons, some variables are only + available in the “wrapper” phase and later. To + “simulate” the wrapper phase, append + PKG_PHASE=wrapper to the above + command.
Installs icons under the - `share/icons/hicolor` hierarchy or updates - `share/icons/hicolor/icon-theme.cache`.	See Section 21.6.19, “Packages installing hicolor theme icons”.
+ 24.6. +	What does + `${MASTER_SITE_SOURCEFORGE:=package/}` mean? I + don't understand the `:=` inside + it.
Installs files under - `share/mime/packages`.	See Section 21.6.14, “Packages installing extensions to the MIME database”.
	The `:=` is not really an + assignment operator, although it looks like it. + Instead, it is a degenerate form of + `${LIST:old_string=new_string}`, + which is documented in the make(1) man page and which is + commonly used in the form `${SRCS:.c=.o}`. In the + case of `MASTER_SITE_`, + `old_string`* is the empty string and + `new_string` is + `package/`. That's where the + `:` and the `=` fall + together.
Installs `.desktop` files under - `share/applications` and these include MIME - information.	See Section 21.6.20, “Packages installing desktop files”.
+ 24.7. +	Which mailing lists are there for package + developers?
	+ tech-pkg + This is a list for technical discussions related + to pkgsrc development, e.g. soliciting feedback for changes to + pkgsrc infrastructure, proposed new features, questions related + to porting pkgsrc to a new platform, advice for maintaining a + package, patches that affect many packages, help requests moved + from pkgsrc-users when an infrastructure bug is found, + etc. + pkgsrc-bugs + All bug reports in category "pkg" sent with + send-pr(1) appear here. Please do not report your bugs here + directly; use one of the other mailing + lists. +
+ 24.8. +	Where is the pkgsrc + documentation?
	+ There are many places where you can find + documentation about pkgsrc: + + The pkgsrc guide (this document) is a collection + of chapters that explain large parts of pkgsrc, but some + chapters tend to be outdated. Which ones they are is hard to + say. + On the mailing list archives (see https://mail-index.NetBSD.org/), you can find discussions + about certain features, announcements of new parts of the pkgsrc + infrastructure and sometimes even announcements that a certain + feature has been marked as obsolete. The benefit here is that + each message has a date appended to it. + Many of the files in the + `mk/` directory start with a comment that + describes the purpose of the file and how it can be used by the + pkgsrc user and package authors. An easy way to find this + documentation is to run bmake + help. + The CVS log messages are a rich source of + information, but they tend to be highly abbreviated, especially + for actions that occur often. Some contain a detailed + description of what has changed, but they are geared towards the + other pkgsrc developers, not towards an average pkgsrc user. + They also only document changes, so if you + don't know what has been before, these messages may not be worth + too much to you. + Some parts of pkgsrc are only “implicitly + documented”, that is the documentation exists only in the + mind of the developer who wrote the code. To get this + information, use the cvs annotate command + to see who has written it and ask on the + `tech-pkg` mailing list, so that others can + find your questions later (see above). To be sure that the + developer in charge reads the mail, you may CC him or + her. + +
+ 24.9. +	I have a little time to kill. +What shall I do?
	+ This is not really an FAQ yet, but here's the answer +anyway. + + Run pkg_chk -N (from the + `pkgtools/pkg_chk` package). It + will tell you about newer versions of installed packages that are + available, but not yet updated in pkgsrc. + Browse `pkgsrc/doc/TODO` + — it contains a list of suggested new packages and a list of + cleanups and enhancements for pkgsrc that would be nice to + have. + Review packages for which review was requested on + the tech-pkg + mailing list. + +

7.2. Settings for creation of binary packages

-Chapter 12. Creating a new pkgsrc package from scratch

+12.1. Makefile +

-12.1. Common types of packages

-12.1.1. Perl modules

+12.3. patches/* +

-12.1.2. Python modules and programs

-12.1.3. R packages

-12.1.4. TeXlive packages

-12.2. Examples

-12.2.1. How the www/nvu package came into pkgsrc

-12.2.1.1. The initial package

-12.2.1.2. Fixing all kinds of problems to make the package work

-12.2.1.3. Installing the package

+12.3.5. Feedback to the author

-Chapter 13. Package components - files, directories and contents

-13.1. Makefile -

-13.2. distinfo -

-13.3. patches/* -

-13.3.1. Structure of a single patch file

-13.3.2. Creating patch files

-13.3.3. Sources where the patch files come from

-13.3.4. Patching guidelines

-13.3.5. Feedback to the author

-13.4. Other mandatory files

-13.5. Optional files

-13.5.1. Files affecting the binary package

-13.5.2. Files affecting the build process

-13.5.3. Files affecting nothing at all

-13.6. work* +12.6. work*

-13.7. files/* +12.7. files/*

-Chapter 14. Programming in Makefiles

-14.1. Caveats

-14.2. Makefile variables

-14.2.1. Naming conventions

+13.3. Directories used during the build process

-14.3. Code snippets

-14.3.1. Adding things to a list

+13.5. The fetch phase

-14.3.2. Echoing a string exactly as-is

-14.3.3. Passing CFLAGS to GNU configure scripts

-14.3.4. Handling possibly empty variables

+13.5.2. How are the files fetched?

-Chapter 15. PLIST issues

+13.6. The checksum phase

-15.1. RCS ID

-15.2. Semi-automatic PLIST generation

-15.3. Tweaking output of make print-PLIST -

-15.4. Variable substitution in PLIST

Legacy note

-15.5. Man page compression

-15.6. Changing PLIST source with PLIST_SRC -

-15.7. Platform-specific and differing PLISTs

-15.8. Build-specific PLISTs

-15.9. Sharing directories between packages

-Chapter 16. Buildlink methodology

-16.1. Converting packages to use buildlink3

-16.2. Writing buildlink3.mk files

-16.2.1. Anatomy of a buildlink3.mk file

-16.2.2. Updating - BUILDLINK_API_DEPENDS.pkg - and - BUILDLINK_ABI_DEPENDS.pkg - in buildlink3.mk files

-16.3. Writing builtin.mk files

-16.3.1. Anatomy of a builtin.mk file

-16.3.2. Global preferences for native or pkgsrc software

-Chapter 17. The pkginstall framework

-17.1. Files and directories outside the installation prefix

-17.1.1. Directory manipulation

-17.1.2. File manipulation

-17.2. Configuration files

-17.2.1. How PKG_SYSCONFDIR is set

+14.1. Common types of packages

-17.2.2. Telling the software where configuration files are

-17.2.3. Patching installations

-17.2.4. Disabling handling of configuration files

-17.3. System startup scripts

-17.3.1. Disabling handling of system startup scripts

-17.4. System users and groups

-17.5. System shells

+14.1.3. R packages

+14.1.4. TeXlive packages

-17.5.1. Disabling shell registration

+12.1. `Makefile` +

+12.3. `patches/*` +

-13.1. `Makefile` -

-13.2. `distinfo` -

-13.3. `patches/*` -

-13.6. `work` +12.6. `work`

-13.7. `files/` +12.7. `files/`

-Chapter 14. Programming in `Makefile`s

-14.2. `Makefile` variables

-14.3.3. Passing `CFLAGS` to GNU configure scripts

-15.2. Semi-automatic `PLIST` generation

-15.6. Changing PLIST source with `PLIST_SRC` -

-16.2. Writing `buildlink3.mk` files

-16.2.2. Updating - `BUILDLINK_API_DEPENDS.pkg` - and - `BUILDLINK_ABI_DEPENDS.pkg` - in `buildlink3.mk` files

-16.3. Writing `builtin.mk` files

-16.3.1. Anatomy of a `builtin.mk` file

-17.2.1. How `PKG_SYSCONFDIR` is set

-18.2. Converting packages to use `bsd.options.mk` -

+Chapter 15. Programming in `Makefile`s

+15.3.3. Passing `CFLAGS` to GNU configure scripts

+16.2. Converting packages to use `bsd.options.mk` +

+18.2.2. Updating + `BUILDLINK_API_DEPENDS.pkg` + and + `BUILDLINK_ABI_DEPENDS.pkg` + in `buildlink3.mk` files

+18.3.1. Anatomy of a `builtin.mk` file

+19.2. Semi-automatic `PLIST` generation

+19.6. Changing PLIST source with `PLIST_SRC` +

+20.2.1. How `PKG_SYSCONFDIR` is set