I am using "dev:watch *" in a karaf container to simplify my testing.
At the moment I deploy all my bundles as "xyz.SNAPSHOT" - and they are picked up correctly.
Question: If I make released bundles (without this ".SNAPSHOT" - will this dev:watch work too?
It won't work with this command:
karaf#root> dev:watch *
From the help of this command:
It will actually monitor all bundles that have a location matching
mvn:* that have '-SNAPSHOT' in their url.
So you need to pass the bundle IDs or urls to the watch command, instead of *. Then Karaf will start watching this non "snapshot" bundles.
Short answer: yes!
The dev:* commands are really useful (dynamic-import is another good one). If you see wiring errors when using dev:watch (i.e. starts referring to two versions of the same bundle, eg. bundle 37.0 and 37.1) then it's a good hint that packages from the original bundle are still being used - this indicates that references aren't being released properly.
Related
Before start describing how I'm getting this error, here is some important information:
It is essential the usage of the module-info.java in my project since jpackage won't work without using it.
I'm using SDK 14.0.2 (this is the minimum version that enables the usage of package)
Every comment will be appreciated; although, if you're going to comment something related to using a specific VM argument, I ask you to press ctrl+F to check if I'm already using the argument you're going to suggest -since there's a bunch of VM arguments in my build.gradle-
Ok, let's take a look about my issue:
First, focus on the VM argument below:
"--add-opens=java.base/java.lang.reflect=com.jfoenix",
If I don't use this argument, the following error pops up when the program runs:
java.lang.reflect.InaccessibleObjectException: Unable to make boolean java.lang.reflect.AccessibleObject.setAccessible0(boolean)
accessible: module java.base does not "opens java.lang.reflect" to module com.jfoenix
IMPORTANT -> This is how my view shows without using the mentioned VM argument (let's call it image 1):
https://snipboard.io/QJ5Fdc.jpg
"Ok, so why don't you just use the VM argument?"
Great question! Alright, let's add it to my VM arguments and run the program once again.
After doing so, this is how my view looks like right now (let's call it image 2): https://snipboard.io/fbhGxw.jpg
Great! This is exactly how my view should be (note that considering it worked as expected, I've got no errors this time).
So, with everything working, I can finally move on and run my jpackage gradle task. After doing so, things stop making sense, since after executing my program through a .exe (generated by jpackage) my view looks like the "image 1" view, regardless the fact that my project is working properly when I run it with the "run" gradle task.
Any thoughts on why is this happening? (My guess is that my module-info.java is the key to solve it, since every time I remove an "opens" statement, e.g.: "opens my.package.name to javafx.fxml", the program gets me almost the equal error).
Let me know whether any code samples will be needed. All assistance will be appreciated. Thanks!
edit: related GitHub issue: enter link description here
I don't know how the jpackage gradle task works, I use the jpackage tool inside the jdk via console and I used this arguments when creating the package
--java-options "--add-opens com.gluonhq.scenebuilder.kit/com.oracle.javafx.scenebuilder.kit.util.control.paintpicker=javafx.fxml --add-opens com.gluonhq.scenebuilder.kit/com.oracle.javafx.scenebuilder.kit.util.control.paintpicker.colorpicker=javafx.fxml"
In there I opened the PaintPicker from scene builder kit to javafx.fxml
As you can see I had to open two packages (they were really five but its too much to put in here) and you have to specify --add-opens for each package to open
I'm putting the code y used to package the application using jpackage
jpackage.exe
--module-path
.;D:\builds\ikonlibrowser\target\ikonlibrowser.jar;
D:\builds\ikonlibrowser\libs\icons\ikonli-antdesignicons-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-bootstrapicons-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-boxicons-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-bpmn-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-captainicon-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-carbonicons-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-codicons-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-coreui-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-dashicons-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-devicons-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-elusive-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-entypo-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-evaicons-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-feather-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-fileicons-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-fluentui-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-fontawesome-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-fontawesome5-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-fontelico-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-foundation-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-hawcons-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-icomoon-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-ionicons-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-ionicons4-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-jamicons-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-ligaturesymbols-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-lineawesome-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-linecons-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-maki-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-maki2-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-mapicons-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-material-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-material2-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-materialdesign-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-materialdesign2-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-medicons-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-metrizeicons-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-microns-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-ociicons-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-octicons-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-openiconic-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-paymentfont-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-prestashopicons-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-remixicon-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-runestroicons-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-simpleicons-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-simplelineicons-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-subway-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-themify-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-typicons-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-unicons-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-weathericons-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-websymbols-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-whhg-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-win10-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-zondicons-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\scenebuilder-kit-16.0.0.jar;
D:\builds\ikonlibrowser\libs\jfoenix-9.0.10.jar
D:\builds\ikonlibrowser\libs\ikonli-core-12.2.0.jar;
D:\builds\ikonlibrowser\libs\ikonli-javafx-12.2.0.jar
--module jcc.app.ikonlibrowser/jcc.app.ikonlibrowser.Main
--name "Ikonli Browser" -d D:\builds\ikonlibrowser
--win-dir-chooser
--input D:\builds\ikonlibrowser\app
--vendor jCC
--app-version "1.0.0"
--java-options
"--add-opens com.gluonhq.scenebuilder.kit/com.oracle.javafx.scenebuilder.kit.util.control.paintpicker=javafx.fxml
--add-opens com.gluonhq.scenebuilder.kit/com.oracle.javafx.scenebuilder.kit.util.control.paintpicker.colorpicker=javafx.fxml
--add-opens com.gluonhq.scenebuilder.kit/com.oracle.javafx.scenebuilder.kit.util.control.paintpicker.rotator=javafx.fxml
--add-opens com.gluonhq.scenebuilder.kit/com.oracle.javafx.scenebuilder.kit.util.control.paintpicker.slider=javafx.fxml
--add-opens com.gluonhq.scenebuilder.kit/com.oracle.javafx.scenebuilder.kit.util.control.paintpicker.gradientpicker=javafx.fxml"
Of course this is only one line.
Now i'll explain it step by step:
--module-path This argument is used to specify the path for all the modules your app uses. Including the application .jar
--module This argument specifies the main class of the application. Putting first the module name and then the class full name.
--name This is to specify the app name.
-d Specifies the output path.
--win-dir-chooser Gives the option to select the installation path when installing the packaged app
--input Specifies a folder containing the external resources for your app
--vendor The vendor's name. Maybe your name
--app-version The version of your application
--java-options The jvm options
I hope it works for you, sorry for the delay.
I have a React application with ApolloClient with Apollo-Link-Schema. The application works fine locally but in our staging environment (using GOCD), we get the following error:
Uncaught Error: Cannot use e "__Schema" from another module or realm.
Ensure that there is only one instance of "graphql" in the node_modules
directory. If different versions of "graphql" are the dependencies of other
relied on modules, use "resolutions" to ensure only one version is installed.
https://yarnpkg.com/en/docs/selective-version-resolutions
Duplicate "graphql" modules cannot be used at the same time since different
versions may have different capabilities and behavior. The data from one
version used in the function from another could produce confusing and
spurious results.
at t.a (instanceOf.mjs:21)
at C (definition.mjs:37)
at _ (definition.mjs:22)
at X (definition.mjs:284)
at J (definition.mjs:287)
at new Y (definition.mjs:252)
at Y (definition.mjs:254)
at Object.<anonymous> (introspection.mjs:459)
at u (NominationsApprovals.module.js:80)
at Object.<anonymous> (validate.mjs:1)
Dependencies are installed with yarn, I've added the resolutions field to the package.json.
"resolutions": {
"graphql": "^14.5.8"
},
I've checked the yarn.lock and can only find one reference for the graphql package.
npm ls graphql does not display any duplicates.
I thought maybe its a build issue with webpack - I have a different build script for staging, but running that locally I am still able to get the react application to run with that bundle.
Can anyone suggest anything else to help me fix this?
I managed to find the cause of the issue, if this helps anyone else. The issue is not to do with duplicate instances of the package at all, this is a false positive triggered by us using webpack's DefinePlugin to set the process.env.NODE_ENV to staging for our staging build.
However, in webpack the mode (see https://webpack.js.org/configuration/mode/), which sets the process.env.NODE_ENV, only accepts none, development and production as valid values. This was triggering an env check in the graphql package to fail and trigger this error message.
In our case, we need to differentiate between staging and production as our API endpoint differs based on this, but the solution we implemented is to not rely on the process.env.NODE_ENV, but to assign a custom variable on build (e.g. process.env.API_URL)
I would try to replicate the error locally and debug it:
try this:
rm -rf node_modules yarn.lock
# also remove any lock files if you have package-lock.json too
yarn install
# build the project locally and see if you got the error
I got this problem one time where I was working with Gatsby and 2 different themes where using different versions of GraphQL. Also be more explicit with the version (without caret) and check if the error persist.
do you have a repo youc an share? that would also help us to help you :)
While changing NODE_ENV to production might solve the issue, if you have different variables for each environment and don't want to mess with your metrics this is not an ideal solution.
You said you use webpack. If the build with the issue uses some kind of source-map in your devtool, you might want to disable that to see if the problem persists. That's how I solved this without setting my NODE_ENV to production.
I had a similar problem when trying to run Apollo codegen and was able to fix it by deduping my npm packages. Run this:
rm -rf node_modules && npm i && npm dedupe
I was having this problem so I switched to yarn, and after deleting node_modules and npm lockfile, then running yarn, the problem went away :-).
I ended up here because I use the AWS CDK and the NodejsFunction Construct. I was also using bundling with minify: true.
Toggling minify to false resolved this for me.
I have an autotools project which successfully builds and tests an app (https://github.com/goglecm/AutoBrightnessCam). The app is installed in the bin directory (preceded by any prefix the user specifies). That's pretty straightforward. I now need to make a systemd service to start it at boot time. I've created the service file and ran it manually and it works fine.
The last bit is to tell configure.ac and Makefile.am to patch a *.service.in file with the correct path for the app (just like config.h is created from config.h.in).
Will using AC_CONFIG_HEADERS be appropriate to patch *.service.in into *.service? Is there another macro used for "non-headers" perhaps?
Also, how do I specify that the service file should land (i.e. installed) in /etc/systemd/system?
Is there perhaps a better way of starting this app at boot time without systemd?
How do I specify that the service file should land (i.e. installed) in /etc/systemd/system?
According to Systemd's daemon man page:
<BEGINQUOTE>
Installing systemd Service Files
At the build installation time (e.g. make install during package build), packages are recommended to install their systemd unit files in the directory returned by pkg-config systemd --variable=systemdsystemunitdir (for system services) or pkg-config systemd --variable=systemduserunitdir (for user services). This will make the services available in the system on explicit request but not activate them automatically during boot. Optionally, during package installation (e.g. rpm -i by the administrator), symlinks should be created in the systemd configuration directories via the enable command of the systemctl(1) tool to activate them automatically on boot.
Packages using autoconf(1) are recommended to use a configure script excerpt like the following to determine the unit installation path during source configuration:
PKG_PROG_PKG_CONFIG
AC_ARG_WITH([systemdsystemunitdir],
[AS_HELP_STRING([--with-systemdsystemunitdir=DIR], [Directory for systemd service files])],,
[with_systemdsystemunitdir=auto])
AS_IF([test "x$with_systemdsystemunitdir" = "xyes" -o "x$with_systemdsystemunitdir" = "xauto"], [
def_systemdsystemunitdir=$($PKG_CONFIG --variable=systemdsystemunitdir systemd)
AS_IF([test "x$def_systemdsystemunitdir" = "x"],
[AS_IF([test "x$with_systemdsystemunitdir" = "xyes"],
[AC_MSG_ERROR([systemd support requested but pkg-config unable to query systemd package])])
with_systemdsystemunitdir=no],
[with_systemdsystemunitdir="$def_systemdsystemunitdir"])])
AS_IF([test "x$with_systemdsystemunitdir" != "xno"],
[AC_SUBST([systemdsystemunitdir], [$with_systemdsystemunitdir])])
AM_CONDITIONAL([HAVE_SYSTEMD], [test "x$with_systemdsystemunitdir" != "xno"])
This snippet allows automatic installation of the unit files on systemd machines, and optionally allows their installation even on machines lacking systemd. (Modification of this snippet for the user unit directory is left as an exercise for the reader.)
Additionally, to ensure that make distcheck continues to work, it is recommended to add the following to the top-level Makefile.am file in automake(1)-based projects:
AM_DISTCHECK_CONFIGURE_FLAGS = \
--with-systemdsystemunitdir=$$dc_install_base/$(systemdsystemunitdir)
Finally, unit files should be installed in the system with an automake excerpt like the following:
if HAVE_SYSTEMD
systemdsystemunit_DATA = \
foobar.socket \
foobar.service
endif
...
</ENDQUOTE>
So it appears you should use systemdsystemunitdir and systemduserunitdir. How well Autotools supports it, well...
A quick grep on Fedora 31 using grep systemdsystemunitdir /bin/autoconf and grep -IR systemdsystemunitdir /usr/share shows no Autotools support yet. 7 years and counting...
Is there perhaps a better way of starting this app at boot time without systemd?
Systemd should be OK to start your app. Simply use systemctl(1) to enable and start them as you normally would.
Based on your GitHub and autobrightnesscam.service.in, I would not dick around with Autotools for this. You can waste copious amounts of time working around Autotols short comings (speaking from experience).
My configure.ac script (which is just a shell script) would copy autobrightnesscam.service.in to autobrightnesscam.service, and then use sed to copy-in the correct directories and files. Then, I would copy the updated autobrightnesscam.service to its proper location in AC_CONFIG_COMMANDS_POST. Maybe something like:
SERVICE_FILE=autobrightnesscam.service
SYSTEMD_DIR=`pkg-config systemd --variable=systemdsystemunitdir`
# Use default if SYSTEMD_DIR is empty
if test x"$SYSTEMD_DIR" = "x"; then
SYSTEMD_DIR=/etc/systemd/system
fi
AC_CONFIG_COMMANDS_POST([cp "$SERVICE_FILE" "$SYSTEMD_DIR"])
AC_CONFIG_COMMANDS_POST([systemctl enable "$SYSTEMD_DIR/$SERVICE_FILE"])
AC_CONFIG_COMMANDS_POST([systemctl start "$SERVICE_FILE"])
Will using AC_CONFIG_HEADERS be appropriate to patch *.service.in into *.service? Is there another macro used for "non-headers" perhaps?
No. AC_CONFIG_HEADERS is for setting up configuration headers to support your build. It is rarely used for anything other than building a config.h recording the results of certain tests that Autoconf performs, and it is not as flexible as other options in this area.
If you have additional files that you want Autoconf to build from templates then you should tell Autoconf about them via AC_CONFIG_FILES. Example:
AC_CONFIG_FILES([Makefile AutoBrightnessCam.service])
But if some of the data with which you are filling that template are installation directories then Autoconf is probably not the right place to do this at all, because it makes provision for the installation prefix to be changed by arguments to make. You would at least need to work around that, but the best thing to do is to roll with it instead, and build the .service file under make's control. It's not that hard, and there are several technical advantages, some applying even if there aren't any installation directory substitutions to worry about.
You can do it the same way that configure does, by running the very same template you're already using through sed, with an appropriate script. Something like this would appear in your Makefile.am:
SERVICE_SUBS = \
s,[#]VARIABLE_NAME[#],$(VARIABLE_NAME),g; \
s,[#]OTHER_VARIABLE[#],$(OTHER_VARIABLE),g
AutoBrightnessCam.service: AutoBrightnessCam.service.in
$(SED) -e '$(SERVICE_SUBS)' < $< > $#
Also, how do I specify that the service file should land (i.e.
installed) in /etc/systemd/system?
You use Automake's standard mechanism for specifying custom installation locations. Maybe something like this:
sytemdsysdir = $(sysconfdir)/systemd/system
systemdsys_DATA = AutoBrightnessCam.service
Is there perhaps a better way of
starting this app at boot time without systemd?
On a systemd-based machine, systemd is in control of what starts at boot. If you want the machine to start your application automatically at boot, then I think your options are limited to
Configuring systemd to start it
Configuring something in a chain of programs ultimately started by systemd to start it
Hacking the bootloader or kernel to start it
There is room for diverging opinions here, but I think the first of those is cleanest and most future-proof, and I cannot recommend the last.
I need to configure WireGuard to bring up a VPN on boot on an Embedded Linux device.
My recipe installs a /etc/wireguard/wg0.conf pretty much like the examples found through the Internet.
Then I try to enable the service on SystemD like this on my wireguard.bb:
SYSTEMD_SERVICE = "wg-quick#wg0.service"
SYSTEMD_AUTO_ENABLE = "enable"
But bitbake throws me an error:
ERROR: Function failed: SYSTEMD_SERVICE_my-conf value wg-quick#wg0.service does not exist
I checked the temporary directory and file wg0.conf appears in the correct places but it seems that bitbake's SYSTEMD_SERVICE doesn't know how to expand the "wg0" after # sign.
If I try without the interface name (wg0):
SYSTEMD_SERVICE = "wg-quick#.service"
Bitbake is happy and finalizes my recipe, but it is not what systemd is expecting. Starting a service without an interface makes no sense...
Then I tried another approach and split the "wireguard" package itself from the configuration ("wireguard-conf" package) and added DEPENDS and RDEPENDS on "wireguard".
This got even worse since my wireguard-conf.bb recipe does not contain a "wg-quick#.service" file (it comes from the dependency "wireguard").
Well,
I don't know how to properly fix it and any suggestions will be highly appreciated.
Additional Info
I am using Yocto 2.0.3 in this project (with no hope of updating it).
Thanks to #TomasNovotny comments I managed to compare my "systemd.bbclas" against Github and noticed a change in systemd_populate_packages() that seems to solve the problem.
It works in newer OpenEmbedded (looks like in krogoth, version 2.1 released Apr 2016) and it is introduced by this commit. It works for me in rocko (version 2.4 released Oct 2017). According to j4x's comment, it doesn't work in jethro (version 2.0, Nov 2015).
For older (and currently unsupported OpenEmbeddeds) you can try to backport the patch or handle the symlinks for enabling the service in do_install().
Also please note that SYSTEMD_SERVICE_${PN} variable is package specific, so the _${PN} suffix has to be added (see manual).
I've also tried to enable OpenVPN with my profile (in Yocto rocko) without success.
Finally, I've made it working by providing OpenVPN recipe extension instead of custom one. So, the openvpn_%.bbappend file looks like:
inherit systemd
SYSTEMD_SERVICE_${PN} = "openvpn#clientprofile.service"
SYSTEMD_AUTO_ENABLE = "enable"
do_install_append() {
install -d ${D}${sysconfdir}/openvpn/
ln -sf /data/etc/openvpn/clientprofile.conf ${D}${sysconfdir}/openvpn/clientprofile.conf
}
As you can see, I'm using a symlink to my profile instead of the normal file. You can install a normal OpenVPN profile file instead of making symlink and it also works fine.
I searched the net and handbook, but I only managed to learn what is the masked package, and not how to install it. I did find some commands, but they don't seem to work on 2008 (looking at it, it seems those are for earlier versions). I have something like this:
localhost ~ # emerge flamerobin
Calculating dependencies
!!! All ebuilds that could satisfy "dev-db/flamerobin" have been masked.
!!! One of the following masked packages is required to complete your request:
- dev-db/flamerobin-0.8.6 (masked by: ~x86 keyword)
- dev-db/flamerobin-0.8.3 (masked by: ~x86 keyword)
I would like to install version 0.8.6, but don't know how? I found some instructions, but they tell me to edit or write to some files under /etc/portage. However, I don't have /etc/portage on my system:
localhost ~ # ls /etc/portage
ls: cannot access /etc/portage: No such file or directory
There are two different kinds of masks in gentoo. Keyword masks and package masks. A keyword mask means that the package is either not supported (or untested) by your architecture, or still in testing. A package mask means that the package is masked for another reason (and for most users it is not smart to unmask). The solutions are:
Add a line to /etc/portage/package.keywords (Check man portage in the package.keywords section). This is for the keyword problems.
Add a line to /etc/portage/package.unmask for "package.mask" problems (you can also use package.mask for the converse). This is in the same man file, under the section package.unmask. I advise to use versioned atoms here to avoid shooting in your own foot with really broken future versions a couple of months down the line.
These days there's also a more 'automated' solution, called "autounmask". No more file editing needed to unmask!
The great benefit of the package is, it also unmasks / handles keywords of dependencies if needed. It's provided in the package app-portage/autounmask.
/etc/portage/package.keywords and
/etc/portage/package.unmask
can be directories as well nowadays (but autounmask handles single files as well). In those directories, multiple can place multiple "autounmask" files, one file in each dir per "unmask"-package. If you use single files instead of dirs, 'autounmask' will place some kind of header / footer, and this way it becomes easy to remove "unmasks" if wanted.
Simply mkdir /etc/portage and edit as mentioned here: http://gentoo-wiki.com/TIP_Dealing_with_masked_packages#But_you_want_to_install_the_package_anyway...