Advantages of combining Portage and Entropy

Discussion in general that pertains to Sabayon Linux - Must Pertain to Sabayon Linux

Moderator: Moderators

Post Reply
Growing Hen
Posts: 175
Joined: Mon Aug 28, 2006 20:57

Advantages of combining Portage and Entropy

Post by pxc » Wed Aug 17, 2011 6:41

[I understand that this could possibly go in either of the package management systems' sub-forums, but as this is about a broader hypothesis rather than a specific technical question, this seemed the most appropriate place to put the thread. My apologies to the mod stuck cleaning up after me in the case that I was wrong. ;-)]

As an advanced, long-time user of Sabayon with additional Gentoo experience, I've always mixed the use of Portage and Entropy on my systems— when I started using Sabayon, there was no Entropy. Despite all of the exclamatory warnings in the wiki about the dangers of this practice, I've actually found it to be surprisingly beneficial in helping me maintain a more stable, complete system. Here's the arrangement I've come to
  • Entropy serves the majority of my package management needs, handling my system updates, and it's my go-to system when looking for new software
  • I manage conflicts between packages which exist both in my Portage tree and the Entropy packageset using complementary entries in /etc/portage/package.* and /etc/entropy/packages/package.*
  • I set up my Entropy system not to ignore whatever packages I've customized with Portage, but usually simply to not to downgrade newer versions of packages I've deliberately upgraded
What I've found to be wonderful about this system is that Portage now serves as my go-to place for experimental, customized, or missing packages while Entropy remains a complete and stable system which I can safely make minor tweaks to, and easily revert back to without lengthy recompilation or similar processes. Since I never use emerge for world updates, I'm left completely free to do all kinds of nasty things to my Portage tree. I've got well over a dozen overlays fetched and managed by layman, as well as a custom repository I added to layman manually, and even several fixed/hacked packages in /usr/local/portage. My overlays have a pretty big range as far as their officialness goes, but when I add a repository I essentially never have to worry about trusting the overall stability or security of the repository. My carefree attitude comes from the fact that I know the short list of individual packages I've installed manually and can retrieve it by poking through my /etc/portage/* files and my /etc/entropy/packages/* files, or searching for spm packages with equo or eix. As a final, nice little reassuring factor, if I fail to make a note of some custom package, or an untrusted (or any Portage) package is pulled in as a dependency during emerge, Entropy will remove it automatically unless I do make a note of it.

Thinking about it now, it may well be possible to set something similar up through the careful use of keywords, masking, and perhaps even the employment of two Portage trees, clean and unclean (basically turning on and off all layman overlays manually instead of adding them in make.conf). Even so, Sabayon's dual-packager system has made this very natural to me, and fast as well. I'm really enjoying it, and I hope Sabayon keeps support for Portage indefinitely. I hope as well that as I continue to use Sabayon, improvements in Entropy, Portage, and my understanding of both will help me further refine this package management workflow I've stumbled into.

So there's my 2¢; a slightly different take on the usual advice regarding Sabayon and Portage. Has anyone else got similar experiences, disaster stories, or tips? I'd like to hear the devs way in on this, if possible.

Young Hen
Posts: 30
Joined: Thu Oct 27, 2011 11:43

Re: Advantages of combining Portage and Entropy

Post by ph03 » Thu Oct 27, 2011 11:56


I'm new to Sabyon but I have used Gentoo for about seven years or so and I do really like its approach and I can completly confirm your experience. I'm also using entropy packages for all base system packages and only use some overlays (like science) and /usr/local/portage ebuilds for packages not available in the entropy world.

However, I'm curious which changes you apply to your /etc/portage/package.* and /etc/entropy/packages/package.* files for, e.g.,
1. a package that is not in entropy but in an local overlay
2. a package that is in entropy but has a newer version installed by portage/emerge form an overlay

I have ignore-spm-downgrades = 1 set but get messages like

Code: Select all

# equo upgrade --ask
>>  @@ Calculating System Updates...
>>  @@ Nothing to update.
>>  @@ On the system there are packages that are not available anymore in the online repositories.
>>  @@ Even if they are usually harmless, it is suggested (after proper verification) to remove them.
>>  @@ These are the packages that should be MANUALLY removed:
>>  ## [spm-db] media-video/glc-0.5.8 [652.1kB]
>>  ## [spm-db] media-gfx/visualizationlibrary-2011.09.1160 [27.7MB]
>>  ## [spm-db] sci-libs/suitesparse-3.6.0 [0.0b]
>>  ## [spm-db] x11-themes/gtk-engines-unico-1.0.1 [76.2kB]
>>  ## [spm-db] sci-libs/armadillo-2.2.3 [1.6MB]
>>  @@ Nothing to remove.
>>  @@ Configuration files scan complete.
on 'equo upgrade', which tells me that it is not configured correctly yet..

Bye J.

Post Reply