down to user support flaws in the FreeBSD ports system. The flaw in question
is related to the fact that dependencies are often "chained", which allows to
simplify maintenance of ports with large number of implied dependencies (a la
Evolution, Nautilus, you-name-it). Dependency chaining it's not a problem by
itself, but the fact that when building or installing a port the system doesn't
check chain integrity - it's only checks that dependencies explicitly
specified in port's Makefile are satisfied, which opens wide window for
various hard-trackable problems when one or more links in the middle of the
chain missed.
The idea behind the tool is quite simple - it should be executed right after
main dependency checking procedure, two times for each build - check build-time
chain before building the port (pre-pre-extract) and check run-time chain
before installing the port (pre-pre-install). When executed, the tool checks
integrity of the specified chain (build-time, run-time or both) and reports all
errors, both fatal (dependency isn't installed) and non-fatal (dependency is
installed, but different version).
I've wrote this tool mostly to simplify maintenance of the GNOME ports, but
it doesn't contain anything GNOME-specific, so that it could be used in the
other parts of tree as well.
As an example I've added GNOME_VALIDATE_DEPS_CHAIN knob into bsd.gnome.mk (off
by default), which enables automatic chain validation for all ports that
USE_GNOMELIBS. This is a bit hackish, because I've used pre-extract and
pre-install targets - what we probably need is a generic way to plug various
custom tasks specified in bsd.xxx.mk (where xxx is kde, gnome, python, etc.)
into various parts of the build process (something like {pre,post}-pre-foo,
{pre,post}-post-foo springs into my mind).
The code is quite raw, so that I would appreciate any bug reports, patches,
suggestions, constructive critiquie and so on.
from telia.dl.sourceforge.net (also known as sourceforge.aleron.net--it
is in the USA, not Sweden), so I have placed it in the first position.
According to Fenner's survey, projects.sourceforge.net and
prdownload.sourceforge.net have been offline since late October and
early November of 2001.
EMACS_MASTERDIR_PKGFILES (default:NO)
If YES, refer pkg-{comment,descr,plist}.${EMACS_PORT_NAME}
in the master directory.
EMACS_NO_SUBDIRSEL (cannot change by users)
Whether emacsen has subdirs.el or not.
Add EMACS_SITE_LISPDIR and EMACS_VERSION_SITE_LISPDIR to SCRIPT_ENV, PLIST_SUB.
Start a transition period:
EMACS_PORT_NAME for emacs-19.x. is from "emacs" to "emacs19"
by will
1) Make selection of AUTO{CONF,MAKE} flexible depending on *_VER
variables.
2) This is backward compatible with previous behavior. For example,
{ACLOCAL,AUTO{CONF,HEADER,MAKE,RECONF,SCAN,UPDATE,IFNAMES}} are
set with default values even if USE_AUTO* are not set.
3) Have the defaults be devel/autoconf213 and devel/automake14 ports
(just set the USE_*VER?= to the latest values, or a bogus value).
If the user sets a bogus value, we use the default values.
4) Furthermore, add variables in the same sense of the
PTHREAD_* vars. We must be able to automagically patch the ports
based on the correct
{ACLOCAL,AUTO{CONF,HEADER,MAKE,RECONF,SCAN,UPDATE,IFNAMES}}
values.
5) Moreover, add {ACLOCAL,AUTO{MAKE,CONF}}_DIR variables pointing
to the right locations based on the *_VER variables, this is
useful if a port needs to grab files from those. This might seem
too much but if we want automagical, we should go this extra
mile.
Requested by: too many
Reviewed by: portmgr, ports
Approved by: portmgr (will), ports (silence)
automatically added if there is a .bz2 patch in PATCHFILES.
PR: ports/16252 and ports/30862
Seven months have passed since the PR was assigned to: portmgr
BZCAT, BZIP2_CMD, CHGRP, CUT, DC, ECHO_CMD, EGREP, FILE, FIND,
HEAD, ID, IDENT, STRIP_CMD, SU, TAIL, TEST, XARGS
And use shell (ash or ksh) builtins where available for efficiency:
ECHO_CMD, FALSE, TEST, TRUE
Grepping the ports tree, a few dozen ports already have FIND,
STRIP_CMD and XARGS variables on their own and numerous ports use
these commands without using macros. Some ports use FILE as a .for
loop variable, but it doesn't matter anyway.
Obtained from: NetBSD
Remove the definition of ECHO because it is already defined in
/usr/share/mk/sys.mk and leaving the useless definition may mislead
developers. Add the following comment that would help:
# ECHO is defined in /usr/share/mk/sys.mk and its value can either be
# "echo", or "true" if the make flag -s is given. Use ECHO_CMD where
# you mean the echo command.
No response yet from: portmgr
Clued by: Cyrille Lefevre <clefevre@citeweb.net> (on ${ECHO})
does not clobber the existing definitions because of the `?='
assignment.
Grepping the whole ports tree, a few dozen ports already define this
variable on their own and most of them have the same value as this
(${PREFIX}/share/examples/${PORTNAME}).
Approved but not committed by: portmgr
As I didn't see why the full package name is needed there, I changed
it to a simple regexp that matches any later version of the XFree86
3.x port.
No response from: portmgr
- Do not shrink series of spaces.
- Do not expand shell wildcards in pkg-comment.
I made the code cleaner and (3-4%) faster while I was at it.
Tested by: diff(1) and its option -b
(Maintainer timeout)
WARNING: This is not for anyone who isn't involved in my group of
KDE/FreeBSD developers & QA testers. Do not use it in any FreeBSD ports.
These changes will be mainly used by modules in the KDE CVS Repository.
This is the fastest way to move forward. A better way would be to
set USE_AUTOCONF and USE_AUTOMAKE to the version desired. We can do that
later, I don't want to hold up the update of the autoconf and automake
ports the latest versions.
less ports have to use NO_LATEST_LINK, and we won't have to keep artificially
setting the PORTNAME to get the Latest link logic to do something reasonable.
Approved by: will
ruby's architecture specific library paths, so that users do not need
to rebuild and reinstall ruby & all the modules when they minor
upgrade FreeBSD.
i.e. i386-freebsd4.4 -> i386-freebsd4
alpha-freebsd5.0 -> alpha-freebsd5
XFREE86_VERSION=4, Mesa3 will not get left out of the install. Previously,
bsd.port.mk would find libGLU.so.1 from XFree86-4 and thus wouldn't install
libglut.so.3 needed by XFree86-4 users for USE_MESA.
PR: 29546
Submitted by: petef
Urged on by for 4.4R: sf
1) Bump PKG_IGNORE_DEPENDS for XFree86 to XFree86-3.3.6_9
2) Modify LDCONFIG_RUNLIST to apply RE multiple times on the
same line. Needed for some ports.
PR: 27645 (1)
Submitted by: Yoichi NAKAYAMA <yoichi@eken.phys.nagoya-u.ac.jp> (1),
demon (2)
Reviewed by: portmgr
