LAYMAN(8)

Brian Dolbec


Table of Contents

1. NAME
2. SYNOPSIS
3. DESCRIPTION
3.1. WARNING
4. OPTIONS
4.1. ACTIONS
4.2. PATH OPTIONS
4.3. OUTPUT OPTIONS:
5. CONFIGURATION
5.1. *NEW*Repo Configuration options
6. HANDLING OVERLAYS
6.1. OVERLAY LISTS
6.2. LOCAL CACHE
6.3. HANDLING /ETC/PORTAGE/MAKE.CONF
6.4. ADDING, REMOVING AND UPDATING OVERLAYS
6.5. NEW DISABLING, AND RE-ENABLING OVERLAYS
6.6. LIST OVERLAYS
6.7. SEARCHING EBUILDS IN OVERLAYS
6.8. OVERLAY TYPES
7. OVERLAY LISTS
7.1. OVERLAY LIST FORMAT
7.2. ADDING AN OVERLAY LOCALLY
7.3. ADDING AN OVERLAY GLOBALLY
8. EXAMPLES
8.1. INSTALLING AN OVERLAY
8.2. SYNCING YOUR OVERLAYS
8.3. PERFORMING SEVERAL ACTIONS AT THE SAME TIME
9. FILES
10. AUTHORS
11. REPORTING BUGS
12. SEE ALSO

1. NAME

layman - manage your local repository of Gentoo overlays

2. SYNOPSIS

layman (-a|--add) (ALL|OVERLAY)

layman (-d|--delete) (ALL|OVERLAY)

layman (-D|--disable) (ALL|OVERLAY)

layman (-E|--enable) (ALL|OVERLAY)

layman (-f|--fetch)

layman (-i|--info) (ALL|OVERLAY)

layman (-L|--list)

layman (-l|--list-local)

layman (-r|--readd) (ALL|OVERLAY)

layman (-s|--sync) (ALL|OVERLAY)

layman (-S|--sync-all)

3. DESCRIPTION

layman is a script that allows you to add, remove, re-add, update, disable, and then re-enable Gentoo overlays from a variety of sources.

3.1. WARNING

layman makes it easy to retrieve and update overlays for Gentoo. In addition it makes it TRIVIAL to break your system.

The Gentoo main tree provides you with high quality ebuilds that are all maintained by Gentoo developers. This will not be the case for most of the overlays you can get by using layman. Thus you are removing the security shield that the standard tree provides for you. You should keep that in mind when installing ebuilds from an overlay.

To ensure the security of your system you MUST read the source of the ebuild you are about to install.

4. OPTIONS

4.1. ACTIONS

List of possible layman actions.

-a OVERLAY, --add=OVERLAY
Add the given overlay from the cached remote list to your locally installed overlays. Specify "ALL" to add all overlays from the remote list.
-d OVERLAY, --delete=OVERLAY
Remove the given overlay from your locally installed overlays. Specify "ALL" to remove all overlays.
-D OVERLAY, --disable=OVERLAY
Disable the given overlay from portage. Specify "ALL" to disable all installed overlays.
-E OVERLAY, --enable=OVERLAY
Re-enable a previously disabled overlay. Specify "ALL" to enable all installed overlays.
-f, --fetch
Fetches the remote list of overlays. You will usually NOT need to explicitly specify this option. The fetch operation will be performed automatically once you run the sync, sync-all, or list action. You can prevent this automatic fetching using the --nofetch option.
-i OVERLAY, --info=OVERLAY
Display all available information about the specified overlay.
-L, --list
List the contents of the remote list.
-l, --list-local
List the locally installed overlays.
-n, --nofetch
Prevents layman from automatically fetching the remote lists of overlays. The default behavior for layman is to update all remote lists if you run the sync, list or fetch operation.
-p LEVEL, --priority=LEVEL

Use this option in combination with the --add.

  • make.conf:: It will modify the priority of the added overlay and thus influence the order of entries in the make.conf file. The lower the priority, the earlier in the list the entry will be mentioned in the make.conf.
  • repos.conf:: It will modify the priority in the repos.conf file, and thus influence the portage overlay priority. Read man portage for more details on overlay priority. Use a value between 0 and 100. The default value is 50.
-r OVERLAY, --readd=OVERLAY
Remove and re-add the given overlay from the cached remote list to your locally installed overlays. Specify "ALL" to re-add all local overlays.
-s OVERLAY, --sync=OVERLAY
Update the specified overlay. Use "ALL" as parameter to synchronize all overlays.
-S, --sync-all
Update all overlays. Shortcut for -s ALL.

4.2. PATH OPTIONS

List of available layman path options.

-c PATH, --config=PATH
Path to an alternative configuration file.
-C PATH, --configdir=PATH
Directory path for all layman configuration information.
-o URL, --overlays=URL
Specifies the location of additional overlay lists. You can use this flag several times and the specified URLs will get temporarily appended to the list of URLs you specified in your config file. You may also specify local file URLs by prepending the path with file://. This option will only append the URL for this specific layman run - edit your config file to add a URL permanently. So this is useful for testing purposes.
-O PATH, --overlay_defs PATH
Path to additional overlay.xml files.

4.3. OUTPUT OPTIONS:

List of layman output options.

--debug-level DEBUG_LEVEL
Outputs layman debugging information. The lower the debug level, the less debugging information you’ll get. Use a value between 0 and 10. 0 means no debugging information, 10 selects all debugging messages. The default debug level is 4.
-k, --nocheck
  • When listing remote overlays (using -L or --list) layman no longer hides overlays, for which you lack the tools to use. By default, layman hides Git repositories if you do not have Git installed. Same applies to Subversion, CVS and so forth.
  • Prevents layman from checking the remote lists of overlays for complete overlay definitions. The default behavior for layman is to reject overlays that do not provide a description or a contact attribute.
-N, --nocolor
Remove color codes from the layman output.
-q, --quiet
Makes layman completely quiet. In quiet mode child processes will be run with stdin closed to avoid running into infinite and blindly interactive sessions. Thus a child process may abort once it runs into an situation with need for human interaction. For example this might happen if your overlay resides in Subversion and the SSL certificate of the server needs manual acceptance.
-Q LEVEL, --quietness=LEVEL
Makes layman less verbose. Choose a value between 0 and 4 with 0 being completely quiet. Once you set this below 3, the same warning as given for --quiet applies.
-v, --verbose
Makes layman more verbose and you will receive a description of the overlays you can download.
-W WIDTH, --width WIDTH
Sets the screen width. This setting is usually not required as layman is capable of detecting the available number of columns automatically.

5. CONFIGURATION

layman reads configuration parameters from the file /etc/layman/layman.cfg by default. This file provides seven possible settings.

storage
Directory that will be used to store the overlays and all additional data layman needs. The default is /var/lib/layman. layman uses a location within the /usr/portage hierarchy instead of /var in order to store its data. This decision has been made to support network file systems. If you have your Gentoo tree on NFS or a similar file system and several machines access the same ebuild repository over the net it will be necessary to also provide all necessary layman data within the hierarchy of the tree. This way the overlays will also have to be synced at one location only.
cache
layman will store the downloaded global list of overlays here. The default is %(storage)s/cache.xml.
installed
layman will store the list of installed overlays here. The default is %(storage)s/installed.xml.
make.conf

This is the portage configuration file that layman will modify in order to make the new overlays available within portage. The default is %(storage)s/make.conf. You could also specify /etc/portage/make.conf directly. But that would mean that you have an external program trying to automatically set variables within this very central configuration file. Since I consider that dangerous I prefer having a very small external file that only contains the setting for PORTDIR_OVERLAY. This file is then sourced at the end of /etc/portage/make.conf. This is the reason why layman suggests running the following after it has been installed.

echo 'source /var/lib/layman/make.conf' >> /etc/portage/make.conf
overlays
Specifies the URL for the remote list of all available overlays. The default is http://www.gentoo.org/proj/en/overlays/repositories.xml. You can specify several URLs here (one per line). The contents will get merged to a single list of overlays. This allows to add a personal collection of overlays that are not present in the global list.
proxy
Specify your proxy in case you have to use one.
nocheck
Set to "yes" if layman should stop worrying about overlays with missing a contact address or the description.
clean_archive
Set to "yes" if layman will delete archive files downloaded when installing archive type overlays. This option is only applicable to remote archive overlays. layman will leave the reponsibility of deleting local archive files up to the user. By default, layman will delete downloaded archive files.
check_official
Set to "no" if you don’t want layman to prompt you for consent during the installation of an unofficial overlay.

Per repository type Add, Sync options.

bzr_addopts , bzr_syncopts , cvs_addopts , cvs_syncopts ,
These are command options to include in the commands sent to perform the desired action.

Per repository type Post Add, Sync hooks.

bzr_postsync , cvs_postsync , darcs_postsync , git_postsync ,
These are commands that are run after each add, sync operation if they are defined.

5.1. *NEW*Repo Configuration options

layman now accepts multiple repository config file options. One being the already standard make.conf option and the other being the repos.conf files that can be placed in /etc/portage/repos.conf/. The below configuration options allow you to alter particular things regarding the repository configuration::

  • conf_type:: Specifies the repo configuration type you wish to use. This can be repos.conf, make.conf, or both separated by a comma. The default value is make.conf.
  • require_repoconfig:: Defines whether a configuration file is needed for the package manager or other multi-repository consumer application.
  • repos_conf:: Specifies the path to the config file for all repos.conf configuration. The default location is /etc/portage/repos.conf/layman.conf.
  • auto_sync:: "yes" or "no" value that defines whether or not you want your layman overlays automatically synced by the portage sync plug-in (requires repos.conf support).

6. HANDLING OVERLAYS

layman intends to provide easy maintenance of Gentoo overlays while not requiring any configuration.

6.1. OVERLAY LISTS

layman allows you to fetch an overlay without the need to modify any configuration files. In order for this to be possible the script needs an external list of possible overlay sources. There is a centralized list available at http://www.gentoo.org/proj/en/overlays/repositories.xml but nothing will prevent you from using or publishing your own list of overlays. The location of the remote lists can also be modified using the --overlays option when running layman.

To get a new overlay added to the central list provided for layman, send a mail to <overlays@gentoo.org>. Gentoo developers may add their overlay entries directly into the list which can be accessed over the CVS repository for the Gentoo website.

You can also use several lists at the same time. Just add one URL per line to the overlays variable in your configuration file. layman will merge the contents of all lists.

layman also allows you to define local files in this list. Just make sure you prepend these path names in standard URL notation with file://. layman also gives you the ability to just add an overlay definition to /etc/layman/overlays/some-overlay.xml and it will be automatically available for actions such as add, delete, info… (see below for file format details)

If you need to use a proxy for access to the Internet, you can use the corresponding variable in the layman configuration file. layman will also respect the http_proxy environment variable in case you set it.

6.2. LOCAL CACHE

layman stores a local copy of the fetched remote list. It will be stored in /var/lib/layman/cache.xml by default. There exists only one such cache file and it will be overwritten every time you run layman.

6.3. HANDLING /ETC/PORTAGE/MAKE.CONF

Since layman is designed to automatically handle the inclusion of overlays into your system it needs to be able to modify the PORTDIR_OVERLAY variable in your /etc/portage/make.conf file. But /etc/portage/make.conf is a very central and essential configuration file for a Gentoo system. Automatically modifying this file would be somewhat dangerous. You can allow layman to do this by setting the make_conf variable in the configuration file to /etc/portage/make.conf.

A much safer and in fact recommended solution to the problem is to let layman handle an external file that only contains the PORTDIR_OVERLAY variable and is sourced within the standard /etc/portage/make.conf file. Just add the following line to the end of your /etc/portage/make.conf file:

source /var/lib/layman/make.conf

/var/lib/layman/make.conf is the default provided in the layman configuration. Change this file name in case you decide to store it somewhere else.

The file does not necessarily need to exist at the beginning. If it is missing, layman will create it for you.

There is also no need to remove the original PORTDIR_OVERLAY variable from the make.conf file. Layman will simply add new overlays to this variable and all your old entries will remain in there.

6.4. ADDING, REMOVING AND UPDATING OVERLAYS

Once a remote list of overlays has been fetched, layman allows to add overlays from the remote list to your system. The script will try to fetch the overlay. If this is successful the overlay information will be copied from the cache to the list of locally installed overlays. In addition layman will modify the PORTDIR_OVERLAY variable to include the new overlay path.

Removing the overlay with layman will delete the overlay without leaving any traces behind.

In order to update all overlays managed by layman you can run the script with the --sync ALL option or the --sync-all flag.

6.5. NEW DISABLING, AND RE-ENABLING OVERLAYS

portage will find installed overlays via your repo config files, whether it be make.conf or repos.conf. If you wish to hide the overlay from portage so that the ebuilds will not be accessible then you can do so with the --disable OVERLAY option. This will then disable the overlay in your repo configurations.

To re-enable them again so that portage can again access the ebuilds of that overlay you can simply do so with the --enable OVERLAY option.

6.6. LIST OVERLAYS

layman provides the --list and --list-local options to print a list of available respectively installed overlays.

Listing will prepend all fully supported overlays with a green asterisk, all non-official overlays with a yellow asterisk and all overlays that you will not be able to use since you do not have the necessary tools installed with a red asterisk.

In the default mode layman will be strict about listing overlays and only present you with overlays that are fully supported. In addition it will complain about overlays that are missing a description field or a contact attribute. This type of behavior has been added with layman 1.0.7 and if you’d like to return to the old behavior you may use the k option flag or set the nocheck option in the configuration file.

6.7. SEARCHING EBUILDS IN OVERLAYS

You can search through the ebuilds available in the overlays on http://overlays.gentoo.org/ by using eix. Emerge the package and run:

update-eix-remote update

Alternatively, you can browse overlays that you have not installed on http://gpo.zugaina.org/.

6.8. OVERLAY TYPES

Currently layman supports overlays that are exported via rsync, CVS, subversion, bzr, darcs, git, mercurial, tar packages, or squashfs images that will be mounted read-only. It also supports the generated overlay type g-sorcery installed with the g-cran package (at time of this writing, only available in the science overlay).

7. OVERLAY LISTS

7.1. OVERLAY LIST FORMAT

Layman uses a central list of overlays in XML format. The file looks like this:

Example 1. An example overlays.xml file

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE repositories SYSTEM "/dtd/repositories.dtd">
<repositories xmlns="" version="1.0">
<repo quality="experimental" status="official">
    <name>gnome</name>
    <description>experimental gnome ebuilds</description>
    <homepage>http://git.overlays.gentoo.org/gitweb/?p=proj/gnome.git;a=summary</homepage>
    <owner type="project">
        <email>gnome@gentoo.org</email>
        <name>GNOME herd</name>
    </owner>
    <source type="git">git://git.overlays.gentoo.org/proj/gnome.git</source>
    <source type="git">http://git.overlays.gentoo.org/gitroot/proj/gnome.git</source>
    <source type="git">git+ssh://git@git.overlays.gentoo.org/proj/gnome.git</source>
    <feed>http://git.overlays.gentoo.org/gitweb/?p=proj/gnome.git;a=atom</feed>
    <feed>http://git.overlays.gentoo.org/gitweb/?p=proj/gnome.git;a=rss</feed>
</repo>
</repositories>

Example 2. An example overlays.xml file with a branch

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE repositories SYSTEM "/dtd/repositories.dtd">
<repositories xmlns="" version="1.0">
<repo quality="experimental" status="official">
    <name><hardened-development></name>
    <description><Development Overlay for Hardened Gcc 4.x Toolchain></description>
    <homepage>http://git.overlays.gentoo.org/gitweb/?p=proj/hardened-dev.git;a=summary</homepage>
    <owner type="project">
       <email>hardened@gentoo.org</email>
    </owner>
    <source type="git" branch="uclibc">git://git.overlays.gentoo.org/proj/hardened-dev.git</source>
    <feed>http://git.overlays.gentoo.org/gitweb/?p=proj/hardened-dev.git;a=atom</feed>
</repo>
</repositories>

Users can specify a branch for an overlay, given one actually exists. This logic is applicable to CVS overlays as well and the branch variable is comparable to specifying a subpath for a CVS repository.

VCS types where the use of "branch" is supported is as follows
  • CVS
  • Squashfs
  • Tar
  • Git
  • Mercurial However, for CVS, Squashfs, and Tar overlays, the branch will be treated as a subpath. If you use the branch variable with any other overlay types aside from the ones listed, it will be ignored.

7.2. ADDING AN OVERLAY LOCALLY

Simply create an overlay list in the format described above and run layman with the -o switch. You need to prepend local file URLs with file://. New is the ability to just add an overlay definition like the above to /etc/layman/overlays/some-overlay.xml and it will be automatically available for actions such as add, delete, info…

7.3. ADDING AN OVERLAY GLOBALLY

The global list of overlays used by layman lies at http://www.gentoo.org/proj/en/overlays/repositories.xml.

All Gentoo developers have access to this location via CVS and can modify the list of overlays.

If you are not a Gentoo developer but wish to get your overlay listed you should contact the Gentoo Overlays team at <overlays@gentoo.org>. You can also join #gentoo-overlays on irc.freenode.net.

8. EXAMPLES

8.1. INSTALLING AN OVERLAY

layman -f -a wrobel

This would add the overlay with the id wrobel to your list of installed overlays.

8.2. SYNCING YOUR OVERLAYS

layman -s ALL

This updates all overlays

8.3. PERFORMING SEVERAL ACTIONS AT THE SAME TIME

layman -f -a wrobel webapps-experimental

This fetches the remote list and immediately adds two overlays

9. FILES

/etc/layman/layman.cfg
Configuration file, holding the defaults for layman
/var/lib/layman/make.conf
Configuration file that layman modifies to register the installed overlay(s) with the package manager
/etc/portage/repos.conf/layman.conf
Configuration file that layman modifies to register the installed overlay(s) with the package manager

10. AUTHORS

11. REPORTING BUGS

Please report bugs you might find at http://bugs.gentoo.org/. Thank you!

12. SEE ALSO

make.conf(5), eix(1), portage(5)