HOWTO: Safely mix Entropy and Portage

From Sabayon Wiki
Jump to: navigation, search
i18n: en it tr

This document will guide you through the process of maintaining a hybrid system (Entropy+Portage).

Before you go any further, there is no necessity to use Portage on your machine to compile packages that are not on the Entropy repositories.

Packages can be compiled in a clean environment with the En:Sabayon Devkit without messing with your current system.

If you intend to mantain an hybrid system (Entropy+Portage) then go ahead.

Mixing Portage and Entropy Safely

Rules and Knowledge

Portage (emerge) is not the primary package manager for Sabayon; this article is for advanced users only. In other words, if this fails for you, it is your fault. You have been warned.

Mixing Portage and Entropy is not recommended without extensive knowledge of both package managers. It is recommended that you pick one or the other for maintaining your system. As every package on Sabayon comes from either Gentoo proper or from Sabayon's Gentoo overlay, using Portage is generally considered unnecessary, there are of course always corner cases.

First of all, when mixing Portage and Entropy, never use Portage to update Portage. Sabayon uses a version of Portage that is hard masked in Portage. This means that you will actually be DOWNGRADING, not upgrading Portage. This one simple mistake can completely break your installation due to differing dependencies at the system level. If you are going to mix and match, ALWAYS use Entropy to upgrade portage.

the command 'emerge portage' should never be issued when mixing and matching package managers

So, how do we get the packages we want installed the way we want them? That is actually fairly easy and it is a two-step process. For each package that you want to install:

# nano -w /etc/portage/package.use/00-sabayon.package.use

Add each package there with the USE flags that you want it to have, including the -USE flags for the flags you don't want it to have that may get added by the make.conf. This overrides the make.conf for that particular package. If your package or USE flags requires new dependencies with specific settings, you will need to add those in here as well. A caveat here, avoid system packages at all costs. It is best to use Entropy to meet all dependencies for any package, prior to emerging the actual package. If it is core to the system either live with it or convert your entire system to Portage only.

In the case that package.use is a folder, you can edit the file /etc/portage/package.use/00-sabayon.package.use/00-sabayon.package.use, or create another file like 01-mypackages.use inside that folder.

Next we need to keep Entropy from messing with our new packages. So you will need to tell Entropy to ignore these packages. This is done by:

# nano -w /etc/entropy/packages/package.mask

You need to make sure that you keep back ups of each of these files every time you edit them. Entropy has been known to insert new versions of these files from time to time thereby destroying any changes that you have made. This can be messy.

After emerging the packages, we need to tell Entropy what we just did, and add them to Entropy's database. This is done with the command:

# equo rescue spmsync --ask

Finally, to prevent Entropy from downgrading our added packages, we need to edit:

# nano -w /etc/entropy/client.conf

Scroll down, until you find: # ignore-spm-downgrades =

Uncomment that line by removing the # , and change it to:

ignore-spm-downgrades = enable

Now, PLEASE remember, that next time you upgrade the system, Entropy wants to revert the changes made in "client.conf",

by asking you to execute: equo conf update, and overwrite the file. Of course we DON'T want that, so select here to keep the old config file.

Following these rules can make mixing and matching between Entropy and Portage safer, not safe, just safer. With these rules you will have not only a history of what you have done, but a pretty good idea of what needs to get undone if your system becomes unstable or unusable. What you have changed is documented in one or the other of those two configuration files.

Truly it is recommended that you make package requests either in the forums or at Make sure to include version numbers and any specific USE flags that you think are needed/unneeded. This may not get you your package right away, but it will get you and others the package.

Using a Portage Overlay

Sometimes an app is missing from Entropy and the Portage Tree but is in an overlay. In this scenario it's helpful to install what you can through Entropy and only install the missing components from the Portage Tree or an overlay.

# equo install layman

To see the list of overlays available, run:

# layman -L

To add an overlay:

# layman -a <overlay-name>

To install an overlay package, it's recommended that you first attempt to install any dependencies you can through Entropy:

# emerge --pretend <category>/<package>

Take the list of dependencies and attempt to install them via equo:

# equo install <dependency1> <dependency2> ... <dependencyN>

Finally, let Portage install the package and any remaining dependencies that Entropy didn't have:

# emerge -av <category>/<package>

Upgrading Portage packages

'equo update' will not update Portage packages, as they will be either masked or not present in Entropy. You also cannot use 'emerge -avDuN @world', as this will replace all binary packages with source-based ones. The correct way to update these packages in Sabayon is:

# emerge -avuN $(equo query revisions 9999 -q)

This works as all Portage packages have a revision of 9999 in Entropy. Note that we have omitted --deep, as that can result in Portage attempting to replace core libraries in Entropy, such as boost or systemd. Make sure you read the list of updates carefully, as new packages may pull in dependencies that can/should be installed via Entropy.

Keeping Portage's configuration files in sync with Entropy

When a Sabayon installation is first created, make.conf and /etc/portage contain the same settings as the Entropy build servers. However, these files are not updated automatically, which means that new Entropy packages may be compiled with different USE flags. This can create problems when mixing Entropy and Portage, because a package emerged with no USE flags specified will have a different configuration to the Entropy version of that package!

The following instructions install a script which will automatically download updates to Portage's configuration files, which may then be accepted/rejected via equo-conf.

Move and rename make.conf so that the directory structure matches the one used on the Entropy build servers.

# arch=$(uname -m | sed -e 's/x86_64/amd64/' -e 's/i.86/x86/')
# mv /etc/make.conf /etc/portage/make.conf.$arch
# cd /etc/portage
# ln -s make.conf.$arch make.conf

Save the following script to /var/lib/entropy/ (or download it from here):

ARCH=$(uname -m)
[[ "$ARCH" == "i686" || "$ARCH" == "x86_64" ]] && ARCH="intel"

# Generates filenames for config file protection
function protect {
    DIR=$(dirname $1)
    FILE=$(basename $1)

    for i in `seq 0 9999`; do
        PROTECTED_FILE=$(printf "%s/._cfg%.4i_%s" $DIR $i $FILE)
        [ -f "$PROTECTED_FILE" ] || return

    echo "Too many config protection files: $i" >&2
    exit 1

# Pull latest files from github
if [ -d $BUILD_DIR ]; then
    git -C $BUILD_DIR pull || exit 1
    git clone "" $BUILD_DIR || exit 1
    git -C $BUILD_DIR config --add branch.master.rebase true

if [ ! -d $BUILD_DIR/conf/$ARCH ]; then
    echo "Unknown architecture '$ARCH'." >&2
    exit 1

# Update files
echo "Updating Sabayon portage files..."
cd $BUILD_DIR/conf/$ARCH/portage

for file in * */*; do
    if [ -f "/etc/portage/$file" ]; then
        if ! cmp -s "/etc/portage/$file" "$file"; then
            protect "/etc/portage/$file"
            cp -n $file $PROTECTED_FILE

    elif [ -f $file ]; then
        echo "WARNING: Skipping $file" >&2

# Don't need to notify the user, because emerge will do that for us (when called from eix-sync)

Modify /etc/eix-sync.conf to contain the following:

! /var/lib/entropy/

The first line will cause eix-sync to update any overlays you have, and the second will call the script.

Run eix-sync to update the Portage Tree and your configuration files, then 'equo conf update' to approve/reject any changes.

equo conf update

Note that if you make any changes to make.conf, etc. (such as setting -march=native), you will be prompted to revert them each time you run eix-sync. To workaround this, commit the changes to the git repository in /var/cache/sabayon-build. e.g.

cd /var/cache/sabayon-build/conf/intel/portage
arch=$(uname -m | sed -e 's/x86_64/amd64/' -e 's/i.86/x86/')
nano -w make.conf.$arch
git add make.conf.$arch
git commit -m "Set -march=native"

These changes will then be rebased on top of any updates. Note however that if an update results in a merge conflict, eix-sync will fail and you will need to manually resolve the conflict.

Additional information:

Final Note

A final note, if you well and truly have broken your system, there is a step that you might consider before re installing. Remove all the changes to package.mask and package.use then issue the command : equo update && equo world --replay. This will reinstall, to the current level in the online database, every single package on your system that Entropy has a match for ... every package. So it is time consuming and bandwidth intensive.


With all that said, please consider carefully why and what you are doing before mixing the two package managers. In the support channel in IRC we can tolerate ignorance and usually will help to cure the problem, but as grandpa said "There ain't no cure for stupid" and you may be treated accordingly.

Good Luck ~Az


Rebuild Python with tk support

First update Portage and overlays, make sure you have "sabayon" in your overlays:

# equo update && equo install eix
# layman -l
* sabayon                   [Git       ] (git://           )
# layman -S && eix-sync

Search for Python with eix:

# eix -C dev-lang python
[U] dev-lang/python
     Available versions:  
        (2.4)   2.4.6
        (2.5)   2.5.4-r4
        (2.6)   2.6.4-r1 (~)2.6.4-r1[1] 2.6.5-r2 2.6.5-r3 (~)2.6.6-r1
        (2.7)   [M](~)2.7
        (3.1)   [m]3.1.2-r3 [m]3.1.2-r4
        {-berkdb bootstrap build +cxx doc elibc_uclibc examples gdbm ipv6 +ncurses +readline sqlite +ssl +threads tk +wide-unicode wininst +xml}                
     Installed versions:  2.6.5-r2(2.6)(16:21:53 04.05.2010)(berkdb gdbm ipv6 ncurses readline sqlite ssl threads wide-unicode xml -build -doc -elibc_uclibc -examples -tk -wininst)                                                            
     Description:         Python is an interpreted, interactive, object-oriented programming language.

[1] "sabayon" /var/lib/layman/sabayon

Look at "Installed versions", here is "2.6.5-r2". Maybe you have more than one version installed, that's no problem.

Edit "/etc/portage/package.use", add "tk" to "dev-lang/python sqlite" -> "dev-lang/python sqlite tk". Maybe set a marker on top of the file: "# 22. okt 2010 add tk to python" or similar.

Now emerge the Python version and check if tk is added:

# emerge -av =python-2.6.5-r2
Calculating dependencies... done!
[ebuild   R   ] dev-lang/python-2.6.5-r2  USE="berkdb gdbm ipv6 ncurses readline sqlite ssl threads tk* (wide-unicode) xml -build -doc -examples -wininst" 10,903 kB

Edit "/etc/entropy/packages/package.mask", add "=dev-lang/python-2.6.5-r2" at the end. Maybe set a marker.

Let Entropy know about the new Python version:

# equo rescue spmsync --ask


Additional info: