Do it for all packages that
* mention perl, or
* have a directory name starting with p5-*, or
* depend on a package starting with p5-
like last time, for 5.18, where this didn't lead to complaints.
Let me know if you have any this time.
a) refer 'perl' in their Makefile, or
b) have a directory name of p5-*, or
c) have any dependency on any p5-* package
Like last time, where this caused no complaints.
to trigger/signal a rebuild for the transition 5.10.1 -> 5.12.1.
The list of packages is computed by finding all packages which end
up having either of PERL5_USE_PACKLIST, BUILDLINK_API_DEPENDS.perl,
or PERL5_PACKLIST defined in their make setup (tested via
"make show-vars VARNAMES=..."), minus the packages updated after
the perl package update.
sno@ was right after all, obache@ kindly asked and he@ led the
way. Thanks!
Shared directories can now be created independently by the pacakges
needing them and will be removed automatically by pkg_delete when empty.
Packages needing empty directories can use the @pkgdir command in PLIST.
Discussed and ok'd in thread starting at
http://mail-index.netbsd.org/tech-pkg/2009/06/30/msg003546.html
This changes the buildlink3.mk files to use an include guard for the
recursive include. The use of BUILDLINK_DEPTH, BUILDLINK_DEPENDS,
BUILDLINK_PACKAGES and BUILDLINK_ORDER is handled by a single new
variable BUILDLINK_TREE. Each buildlink3.mk file adds a pair of
enter/exit marker, which can be used to reconstruct the tree and
to determine first level includes. Avoiding := for large variables
(BUILDLINK_ORDER) speeds up parse time as += has linear complexity.
The include guard reduces system time by avoiding reading files over and
over again. For complex packages this reduces both %user and %sys time to
half of the former time.
The System Tools Backends (s-t-b for short) are a set of cross-platform
modules for Linux, FreeBSD and other Unix systems. The backends provide a
common DBus interface to all platforms to modify or read the system
configuration in a distro independent fashion. Historically, access to
system configuration has varied deeply across Unix flavours, and concreting
a bit more, across Linux distributions, making it near impossible to write
desktop tools that could work flawlessly in a cross-platform way. System
Tools Backends try to fill this gap, offering a generic and easy way for
desktop applications to read and modify configuration details.
