and documented in mk/defaults/mk.conf. Both the "gpg" and "x509" methods
supported by pkg_admin(1) are supported. With package signing enabled, a
staging, unsigned copy of the package is always created, and its final copy
to the package repository is done with pkg_admin(1) instead of "ln || cp".
Proper operation should otherwise not be affected.
Tested both with and without user-destdir support in packages.
"can live with it" joerg@
From EdgeBSD.
SMF is the Service Management Facility, the default init system in
Solaris and derivatives since version 10. This adds "smf" to the list
of supported INIT_SYSTEM types, and makes it the default init system on
platforms where it is available.
Packages can introduce SMF support by providing a manifest file, by
default located in ${FILESDIR}/smf/manifest.xml but manifests under
${WRKSRC} can be used too if the package source includes one.
SMF method scripts are supported too if required, using SMF_METHODS in a
similar manner to RCD_SCRIPTS.
Many parts of the SMF infrastructure are configurable, see mk/smf.mk for
the full details.
This commit introduces an INIT_SYSTEM variable which will determine the
type of init system to be used on the target system, supporting "rc.d"
at this time.
The pkginstall infrastructure is changed to only install RCD_SCRIPTS if
INIT_SYSTEM is set to "rc.d", and PLIST entries for rc.d scripts are
now handled automatically based on RCD_SCRIPTS.
As the default fetch program "tnftp" (in "pkgsrc" and all released
versions of NetBSD) doesn't support HTTPS prefer "fetch" (DragonFlyBSD,
FreeBSD and Minix) or Curl (CygWin, Linux, Mac OS X, Solaris) if available.
Change during pkgsrc-freeze approved by Greg Troxel and Thomas Klausner.
turned off in www/curl.
Modify the curl package to be aware of the libidn option. Ensure default
is on.
No functional change, so no version number bump.
By default pkgsrc uses LOCABASE/gnu as a prefix for packages to install
native versions of GNU tools, which are them symbolically linked back to
the 'g' versions of the files in LOCALBASE, and users can then add
LOCALBASE/gnu/bin to PATH to pick up those tools.
On systems where the GNU environment is desired, PKGGNUDIR now allows
users to install the non-'g' files directly into LOCALBASE, making them
the default without having to alter PATH, whilst retaining the 'g' files
in order to ensure dependencies and tool paths remain the same.
where software assumes features of the native 'tar' and break when 'tar' is
the NetBSD version.
We are too close to the pkgsrc-2012Q2 branch to remove NBPAX_PROGRAM_PREFIX
completely, but if it's apparent that no platforms need to override this
default then it will be removed completely for the next branch.
For a long time, the norm in pkgsrc was that packages had an option
for IPv6 support "inet6", and this was not in PKG_SUGGESTED_OPTIONS.
On NetBSD (and probably other BSD), USE_INET6 was defined in system mk
files, and pkgsrc noticed this and enabled the inet6 option globally.
But, in some environments, this did not happen.
The inet6 option has been added to PKG_SUGGESTED_OPTIONS for almost
all packages. This change decouples IPv6 support in pkgsrc from the
base system.
People building on systems that do not support IPv6, or who do not
want IPv6 support in packages, can add
PKG_DEFAULT_OPTIONS+= -inet6
to mk.conf.
(Discussed for the last week on various lists, and ok wiz@.)
Always use xorg-cf-files and imake from pkgsrc, replacing xpkgwedge.
Always install man pages, not cat pages when using imake.
Unify the various imake PLIST variables in preparation for dropping.
Adjust xbattbar for the new expectations.
Added missing -i option to mshortname
Make it clear that label is limited to 11 characters
mbadblocks now takes a list of bad blocks
mbadblocks now is able to do write scanning for bad blocks
mshowfat can show cluster of specific offset
Fixed encoding of all-lowercase names
Consider every directory entry after an ENDMARK (0x00) to be deleted
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.
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.
