pkgsrc/doc/pkgsrc.txt - diff

Return to pkgsrc.txt CVS log

Up to [cvs.NetBSD.org] / pkgsrc / doc

Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.

Diff for /pkgsrc/doc/pkgsrc.txt between version 1.125 and 1.126

version 1.125, 2009/05/17 23:36:01

version 1.126, 2009/08/25 13:20:58

Line 1597 As mentioned above, packages for which v

in the All subdirectory. They don't get deleted since that could be very

frustrating if many other packages depend on it. Instead, they are moved to the

vulnerable subdirectory. So you may need to add this directory to the PKG_PATH

variable. However, you should run audit-packages regularly, especially after

variable. However, you should run pkg_admin audit regularly, especially after

installing new packages, and verify that the vulnerabilities are acceptable for

your configuration.

Line 1634 security vulnerabilities to packages whi

pkgsrc. The list is available from the NetBSD FTP site at ftp://ftp.NetBSD.org/

pub/pkgsrc/distfiles/vulnerabilities.

Through security/audit-packages, this list can be downloaded automatically, and

Through pkg_admin fetch-pkg-vulnerabilities, this list can be downloaded

a security audit of all packages installed on a system can take place.

automatically, and a security audit of all packages installed on a system can

take place.

There are two components to security/audit-packages. The first component,

"download-vulnerability-list", is for downloading the list of vulnerabilities

There are two components to auditing. The first step, pkg_admin

from the NetBSD FTP site. The second component, "audit-packages", checks to see

fetch-pkg-vulnerabilities, is for downloading the list of vulnerabilities from

if any of your installed packages are vulnerable. If a package is vulnerable,

the NetBSD FTP site. The second step, pkg_admin audit, checks to see if any of

you will see output similar to the following:

your installed packages are vulnerable. If a package is vulnerable, you will

see output similar to the following:

Package samba-2.0.9 has a local-root-shell vulnerability, see

http://www.samba.org/samba/whatsnew/macroexploit.html

One can set up security/audit-packages to download the vulnerabilities file

You may wish to have the vulnerabilities file downloaded daily so that it

daily, and include a package audit in the daily security script. Details on

remains current. This may be done by adding an appropriate entry to the root

this are located in the MESSAGE file for security/audit-packages.

users crontab(5) entry. For example the entry

# download vulnerabilities file

0 3 * * * /usr/sbin/pkg_admin fetch-pkg-vulnerabilities >/dev/null 2>&1

will update the vulnerability list every day at 3AM. You may wish to do this

more often than once a day. In addition, you may wish to run the package audit

from the daily security script. This may be accomplished by adding the

following line to /etc/security.local:

/usr/sbin/pkg_admin audit

4.1.6. Finding if newer versions of your installed packages are in pkgsrc

Line 1913 each variable's intent.

Line 1926 each variable's intent.

* BINPKG_SITES: List of sites carrying binary pkgs. rel and arch are replaced

with OS release ("2.0", etc.) and architecture ("mipsel", etc.).

* ACCEPTABLE_LICENSES: List of acceptable licenses. Whenever you try to build

* ACCEPTABLE_LICENSES: List of acceptable licenses. License names are

a package whose license is not in this list, you will get an error message

case-sensitive. Whenever you try to build a package whose license is not in

that includes instructions on how to change this variable.

this list, you will get an error message. If the license condition is

simple enough, the error message will include specific instructions on how

to change this variable.

5.2. Variables affecting the build process

Line 2270 that file.

Line 2285 that file.

You may want to set variables in mk.conf. Look at pkgsrc/mk/defaults/mk.conf

for details of the default settings. You will want to ensure that

ACCEPTABLE_LICENSES meet your local policy. As used in this example,

_ACCEPTABLE=yes completely bypasses the license check.

SKIP_LICENSE_CHECK=yes completely bypasses the license check.

PACKAGES?= ${_PKGSRCDIR}/packages/${MACHINE_ARCH}

WRKOBJDIR?= /usr/tmp/pkgsrc # build here instead of in pkgsrc

Line 2279 BSDXSRCDIR= /usr/xsrc # for

Line 2294 BSDXSRCDIR= /usr/xsrc # for

OBJHOSTNAME?= yes # use work.`hostname`

FAILOVER_FETCH= yes # insist on the correct checksum

PKG_DEVELOPER?= yes

_ACCEPTABLE= yes

SKIP_LICENSE_CHECK= yes

Some options that are especially useful for bulk builds can be found at the top

lines of the file mk/bulk/bsd.bulk-pkg.mk. The most useful options of these are

Line 2637 might set now are:

Line 2652 might set now are:

* ACCEPTABLE_LICENSES+=..., to select some licenses additional to the usual

Free/Open Source licenses that are acceptable to you,

* _ACCEPTABLE=yes, to accept all licenses, no matter how restrictive they

* SKIP_LICENSE_CHECK=yes, to bypass the license checks.

are.

Now you are ready to build the rest of the pbulk infrastructure.

Line 4629 following files:

Line 4643 following files:

13.8. Sharing directories between packages

A "shared directory" is a directory where multiple (and unrelated) packages

install files. These directories are problematic because you have to add

install files. These directories were problematic because you had to add

special tricks in the PLIST to conditionally remove them, or have some

centralized package handle them.

Within pkgsrc, you'll find both approaches. If a directory is shared by a few

In pkgsrc, it is now easy: Each package should create directories and install

unrelated packages, it's often not worth to add an extra package to remove it.

files as needed; pkg_delete will remove any directories left empty after

Therefore, one simply does:

uninstalling a package.

@unexec ${RMDIR} %D/path/to/shared/directory 2>/dev/null || ${TRUE}

in the PLISTs of all affected packages, instead of the regular "@dirrm" line.

However, if the directory is shared across many packages, two different

solutions are available:

1. If the packages have a common dependency, the directory can be removed in

that. For example, see textproc/scrollkeeper, which removes the shared

directory share/omf.

2. If the packages using the directory are not related at all (they have no

If a package needs an empty directory to work, create the directory during

common dependencies), a *-dirs package is used.

installation as usual, and also add an entry to the PLIST:

From now on, we'll discuss the second solution. To get an idea of the *-dirs

@pkgdir path/to/empty/directory

packages available, issue:

% cd .../pkgsrc

% ls -d */*-dirs

Their use from other packages is very simple. The USE_DIRS variable takes a

list of package names (without the "-dirs" part) together with the required

version number (always pick the latest one when writing new packages).

For example, if a package installs files under share/applications, it should

have the following line in it:

USE_DIRS+= xdg-1.1

After regenerating the PLIST using make print-PLIST, you should get the right

(commented out) lines.

Note that even if your package is using $X11BASE, it must not depend on the

*-x11-dirs packages. Just specify the name without that part and pkgsrc (in

particular, mk/dirs.mk) will take care of it.

Chapter 14. Buildlink methodology

Line 5780 would look like:

Line 5761 would look like:

MASTER_SITES= http://www.example.com/download.cgi?file=

The exception to this rule are URLs starting with a dash. In that case the URL

is taken as is, fetched and the result stored under the name of the distfile.

There are some predefined values for MASTER_SITES, which can be used in

packages. The names of the variables should speak for themselves.

Line 7756 the tree needs to be updated.

Line 7740 the tree needs to be updated.

Note

Except the main TeX packages such as teTeX-texmf, packages should install files

Except the main TeX packages such as kpathsea, packages should install files

into PKG_LOCALTEXMFPREFIX, not PKG_TEXMFPREFIX.

into ${PREFIX}/share/texmf-dist, not ${PREFIX}/share/texmf.

1. Include ../../print/teTeX/module.mk instead of ../../mk/tex.buildlink3.mk.

1. Include ../../print/kpathsea/texmf.mk. This takes care of rebuilding the

This takes care of rebuilding the ls-R database at installation and

ls-R database at installation and deinstallation time.

deinstallation time.

2. If your package installs files into a texmf tree other than the one at

2. If your package installs files into a texmf tree other than the one at $

PKG_LOCALTEXMFPREFIX, set TEXMFDIRS to the list of all texmf trees that

{PREFIX}/share/texmf-dist, set TEX_TEXMF_DIRS to the list of all texmf

need database update.

trees that need database update.

If your package also installs font map files that need to be registered

using updmap, set TEX_FONTMAPS to the list of all such font map files. Then

using updmap, include ../../print/texlive-tetex/map.mk and set

updmap will be run automatically at installation/deinstallation to enable/

TEX_MAP_FILES and/or TEX_MIXEDMAP_FILES to the list of all such font map

disable font map files for TeX output drivers.

files. Then updmap will be run automatically at installation/deinstallation

to enable/disable font map files for TeX output drivers.

3. Make sure that none of ls-R databases are included in PLIST, as they will

be removed only by the teTeX-bin package.

Line 7822 is to regenerate it using make print-PLI

Line 7806 is to regenerate it using make print-PLI

19.7. Marking packages as having problems

In some cases one does not have the time to solve a problem immediately. There

In some cases one does not have the time to solve a problem immediately. In

are currently two ways to declare that one knows that a package has problems.

this case, one can plainly mark a package as broken. For this, one just sets

the variable BROKEN to the reason why the package is broken (similar to the

* The first way is to plainly mark it as broken. For this, one just sets the

RESTRICTED variable). A user trying to build the package will immediately be

variable BROKEN to the reason why the package is broken (similar to the

shown this message, and the build will not be even tried.

RESTRICTED variable). A user trying to build the package will immediately

be shown this message, and the build will not be even tried.

* After each pkgsrc freeze period (a time when the tree is stabilized and a

new pkgsrc branch is cut), the packages that were not building in the

official branch build on the latest NetBSD release will be marked as broken

on that branch. This is done by setting the BROKEN_IN variable to the

branch name (or appending the branch name to it). If a user tries to build

such a package and the build fails, the user gets a message that says that

the package was broken on the respective branch(es).

Both types of packages are removed from pkgsrc in irregular intervals.

BROKEN packages are removed from pkgsrc in irregular intervals.

Chapter 20. Debugging

Line 7988 general usage is to first make sure that

Line 7962 general usage is to first make sure that

directory. For package updates, make changes-entry is enough. For new packages,

or package moves or removals, set the CTYPE variable on the command line to

"Added", "Moved", or "Removed". You can set NETBSD_LOGIN_NAME in mk.conf if

your local login name is not the same as your NetBSD login name. Don't forget

your local login name is not the same as your NetBSD login name. The target

to commit the changes to pkgsrc/doc/CHANGES-YYYY!

also automatically removes possibly existing entries for the package in the

TODO file. Don't forget to commit the changes, e.g. by using make

changes-entry-commit! If you are not using a checkout directly from

cvs.netbsd.org, but e.g. a local copy of the repository, you can set

USE_NETBSD_REPO=yes. This makes the cvs commands use the main repository.

21.4. Committing: Importing a package into CVS

CVSweb <webmaster@jp.NetBSD.org>