A variable name that should be set as staged installation location
presented as ${DESTDIR} at installation phase.
"DESTDIR" is set by default.
for packages using different variable for staged installation prefix,
and/or using DESTDIR variable for different purpose.
as GIF implementation. They are src/binary compatible and mutually
exclusive, so this is a global choice.
Up to now, "libungif" is used by pkgs, due to patent problems. The
patents are said to be expired, and "giflib" gets somewhat better
maintainance upstream these days, so set the new default to "giflib".
Solaris 11 Express, too).
Changes 4.4.5:
The GNU project and the GCC developers are pleased to announce the
release of GCC 4.4.5.
This release is a bug-fix release, containing fixes for regressions in
GCC 4.4.4 relative to previous releases of GCC.
default in mk/defaults/mk.conf
remove the non-shared defaults and put in the setting that actually gets
used by more than one package (namely, MAJORDOMO_HOMEDIR)
don't make the majordom user own more than it actually needs to
make resend, archive, request-answer and medit honor the MAJORDOMO_CF
environment variable over the command line option, so that someone calling
these via the wrapper (which sets the environment variable) can't make
the majordom user execute random perl code by specifying it as config file.
Thanks to salo for finding this issue.
The problem is Darwin's libiconv does not have symbols for libiconv_<name>
(e.g. libiconv_open), but iconv_<name> (e.g. iconv_open).
BUT when there's pkgsrc/converters/libiconv installed instead, it doesn't
have symbols for iconv_<name>, but libiconv_<name>.
Some packages auto-configure looks for libiconv_open (like glib2), others
look for iconv_open (like proftpd), and there's a conflict.
The solution is to replace libiconv_open with iconv_open with SUBST framework.
Welcome to the modern world of computing.
This is known to break DragonFly at least,
either port g95 or fix lang/gcc44 to work on NetBSD.
Unless there're packages that still think that Fortran is F77,
this shouldn't affect anything.
outdated X libraries? Default to modular x11 for a more modern set of
features, bugfixes (and bugs), and to simplify application support
Does *not* affect 10.5 (Leopard) or later
require a libjpeg implementation. jpeg.buildlink3.mk will:
* set JPEGBASE to the base directory of the libjpeg files;
* set JPEG_TYPE to the libjpeg implementation used.
There are three variables that can be used to tweak the selection of
the libjpeg implementation:
JPEG_DEFAULT is a user-settable variable whose value is the default
libjpeg implementation to use.
JPEG_ACCEPTED is a package-settable list of libjpeg implementations
that may be used by the package.
This .mk is broadly based on fam.buildlink3.mk,v 1.7, and
currently supports selection between the default "graphics/jpeg"
and the alternative "graphics/libjpeg-turbo".
Removes overbroad use of -f to override the
depending-packages-have-satisfied-dependencies check, replacing with
the narrow override of -D.
Discussed on tech-pkg@.
OK pkgsrc-pmc@.
can't be disabled by setting it to "no" like the other variables.
Besides, flavor/pkg/metadata.mk has been expecting for a long time that "no"
is a valid value.
Make PKG_DEVELOPER DWIM.
* Introduce USE_GAMESGROUP, which causes the games user and group to
be made available.
* Retain SETGIDGAME as an alias for USE_GAMESGROUP. Describe it as
deprecated.
* Always define GAMES_USER, GAMES_GROUP, GAMEMODE, GAMEDIRMODE, and
GAMEDATAMODE, regardless of whether USE_GAMESGROUP is turned on or not.
* Define these variables in defaults/mk.conf instead of separately in
every platform/*.mk file. The definitions used to be the same for each
of these platforms anyway, except for some where they were randomly
missing or commented out for no clear reason, leading to broken game
packages.
* Handle all these variables properly when unprivileged.
* Update the comments/documentation for these variables.
* Describe GAMEOWN and GAMEGRP as deprecated. These need to be
retained as aliases for GAMES_USER and GAMES_GROUP respectively for
supporting packages that use bsd.*.mk but should otherwise not be
used.
* Add GAMEDATA_PERMS and GAMEDIR_PERMS using GAMEDATAMODE and
GAMEDIRMODE respectively.
* Fix a bug I noticed that was improperly mixing the "games" group
and "games" user.
Things this does *not* do:
- get rid of GAMES_USER, for which there should ultimately be no need.
- move the declaration/documentation/default value of USE_GAMESGROUP
to a suitable place. (It is currently where SETGIDGAME was, which is
suboptimal.)
- touch any of the games, all of which need updating with at least
s/SETGIDGAME/USE_GAMESGROUP/ and probably more.
- update the guide to explain how to handle games properly.
Also, it would be nice if using GAMES_GROUP without setting
USE_GAMESGROUP=yes caused an error but as far as I know there isn't
any particularly good way to arrange this right now.
Note that these changes may alter the build/install behavior of broken
game packages, e.g. some may silently become setgid when they weren't
before or things like that. If you run into any of this file a PR.
While one might arguably bump the PKGREVISION of all games or other
packages using any of these variables as a precaution, that seems like
a bad idea. Instead, I think I will be bumping each game once it
itself has been fixed up to do everything the right way.
libpthread -- it is generally under the program's control which modules
to load, a general rule is just too much
I've been using this modification for over a year without problems.
course a too-large hammer, but in addition to overriding checks it
appears to change behavior in some cases when no overrides are
necessary. Therefore, use pkg_add -U as before first, and only try -f
if that fails. (This is temporary and should be replaced by -D to
omit only the exact depends check as soon as that's in tree.)
update", so if it's going to fail because of a known vulnerability it
does so before uninstalling anything. I've been carrying this patch
for some three years with no ill effects. Ok by agc@.
"make replace" is defined to replace a package with a newer version,
and update depdending packages to depend on the new version. It has
long been understood that this is not always safe, with the responses
being "tell people to be careful" and the unsafe_depends variable
scheme and pkg_rolling-replace. In the DESTDIR case, make replace is
implemented by pkg_add -U. Usually, this is fine - even if the
ABI/shlib majors have changed, the package is replaced, and then a
later make replace of unsafe_depends=YES packages, either manually or
via pkg_rolling-replace, will bring the system to where it should be.
However, there are pinned dependencies on osabi where the depending
package will not accept the new version, and that causes pkg_add -U to
fail. This is incorrect, as a) those packages don't depend on the
osabi exact version any more than packages depending on jpeg depeend
on the particular shlib major, yet jpeg dependencies aren't pinned.
And, osabi changing version is not necessarily an ABI change -
consider 5.0_STABLE just before 5.1RC1 and just after, where only the
version string changed.
Therefore, add -f to pkg_add -U so that the update will succeed.
hardcoding the logic into the pkginstall scripts. As discussed in
tech-pkg@.
Note: The current pkginstall/shell code is overly complicated. It looks
like it can be simplified but, at the moment, given that I do not understand
the need for such complexity, I'm just doing this tiny change.
Note 2: The ability to update /etc/services, which was also discussed, will
come later once this change proves to be stable.
The [1]GNU project and the GCC developers are pleased to announce the
release of GCC 4.4.4.
This release is a bug-fix release, containing fixes for regressions in
GCC 4.4.3 relative to previous releases of GCC.
