update world question (mixing with equo)

[King_DuckZ]

Hello, I hope this is the right section to post.
I've been using Sabayon for a while now, but I still have lots of doubts when upgrading or installing software. I use equo as the main repository for my system, but for some packages I want to use emerge. As suggested in some wiki page I found, I masked in equo the packages I installed via emerge, so my packages.mask looks like this:

Code: Select all

# package.mask example file
#
# In this file you can specify atoms, one per line, that you would mask.
# Masking a package (atom) means that you will deny Entropy to pull in a package even if it's marked as "NOT experimental".

# LINE CONSTRUCTION:
# <atom>
# See examples below

# EXAMPLES:
# >=media-libs/foo-1.2.3
# media-libs/foo
# <media-libs/foo-1.2.3
# media-libs/foo:1
# >=media-libs/foo-1.2.3#2.6.23-sabayon-r1
#
# :1 means package with SLOT="1"
# #2.6.23-sabayon-r1 means package with kernel tag = 2.6.23-sabayon-r1

#Vim e le sue dipendenze - 111008 King_DuckZ
app-admin/eselect-vi
app-admin/eselect-ctags
dev-util/ctags
app-editors/vim-core
app-editors/vim
app-vim/gentoo-syntax

#Git e le sue dipendenze - 111008 King_DuckZ
dev-vcs/subversion
dev-vcs/git

#urxvt e le sue dipendenze - 111008 King_DuckZ
media-libs/libafterimage
x11-terms/rxvt-unicode

#snes9x - 111008 King_DuckZ
games-emulation/snes9x

#naev - 111010 King_DuckZ
games-strategy/naev

#ccline e le sue dipendenze - 111010 King_DuckZ
dev-lang/lua
media-libs/libquvi-scripts
media-libs/libquvi
media-video/cclive

#cmus - 111010 King_DuckZ
media-sound/cmus

To be honest, I only masked the packages I installed explicitly, and not the dependencies that emerge was pulling in, so this already I'm not sure if it's correct (sometimes I did, but I'm not sure it was a good idea either).
Now, those packages are never updated by equo, right? So my question is: how do I update them?
If I run emerge -ua @world (btw what's the @?) it gathers a long list of things that I don't want emerge to touch, like wget, patchelf and other stuff that doesn't seem to be a dependency for anything in my package.mask. Running emerge on each package manyally would be impractical, and keeps me from using it to install new packages (it would just make the list longer).
Anyways, emerge fails complaining about:

Code: Select all

[blocks B      ] <sys-apps/sysvinit-2.88-r3 ("<sys-apps/sysvinit-2.88-r3" is blocking sys-apps/util-linux-2.20.1)

which again, should be managed solely by equo imo. So, I'm pretty confused, how should I mix the two systems? What's the best way to upgrade emerge's packages? Sorry if this sounds a bit generic, but I'm confused myself

[Stupot]

The best way is to emerge each portage package separately. That's one of the reasons why it's not a good idea to install many packages from portage on a mainly entropy system.

Assuming you didn't mask any of the dependencies for your portage-installed applications, you should update those dependencies with entropy (#equo update && equo upgrade). If there is still a conflict after this, your choices are:

1) Abandon installing that portage application for now.
2) Figure out what other packages you need to install from portage to get it to work (fair warning: depending on what you are installing, you can break other applications)

However, I think the better question to address is, why are you installing so many packages from portage?

If it is because the packages aren't in entropy, then it would be best if you filled out a bug request to have them added to the entropy repos.

If it's because you want newer packages than what is available in entropy for a whole lot of applications, then mixing entropy and equo will always be an aggravating hassle. You would be better off going straight portage or waiting for the packages to update in entropy than mixing the two.

[King_DuckZ]

Last time I checked Ekopath wasn't in Entropy at all, so at least for that one I have to rely on portage. That's ok though, as it doesn't have any dependencies (that I didn't already have at the moment of installation, at least).
For the other programs, the purpose is to build them with custom flags mostly, to have the most updated version or just to play around with portage in other less important cases.
So this brings me to a question: what's the point in supporting two repos if the use of one is strongly discouraged? I see the risks in mixing the two, especially if I edit make.conf and rebuild some low level dependency. Still, I'm interested in using portage. Could this possibly mean that Sabayon might deprecate portage?

The main reason that made me switch to Sabayon is probably Ekopath. The second is that I often need the most updated version of certain softwares, like gcc. Back on Mandriva, I had my own build in my home dir, and you can imagine the hassle deriving from an altered LD_LIBRARY_PATH, from skipping the rpm manager and maintaining my own build script. So, although I'm no build-it-all-myself fanatic, in some cases I really prefer to build the package myself.
I would gladly do something if I can help in improving this aspect of Sabayon.

[Stupot]

You can request that Ekopath be included into Entropy. That would solve one issue.

I understand building packages with custom flags sounds like a grand idea, but what exactly are you doing it for? If packages are missing functionality, you can request to have flags added to packages. If you are looking to gain performance optimizations, then I'm sorry to say that you probably aren't gaining much performance improvement. Even if you compile every package and the kernel so it's optimized for your system, you would probably only gain 10-15% improvement, if that.

Sabayon used to be portage only. However, as much fun as portage is, Fabio saw that for the vast majority of Sabayon users, compiling every package just wasn't worth it. The performance gains just weren't really there, or if they were, they were complicated to achieve and maintain. But portage is also very mature and offers some great advantages for compiling packages. So Entropy is built to use portage. That is why Sabayon systems can use both entropy and portage. Packages in entropy are compiled using portage and are basically binary portage packages.

But, as you already know, the issue is binary packages expect other packages to be compiled with the same flags. Incompatibilities can cause problems.

So, I guess that to answer to your question, it's not that the use of entropy is encouraged and the use of portage is discouraged. It is the use of them together that is discouraged. The fact that it can be done, doesn't mean it necessarily should be. However, when you look at it from a developer stand point, it is impossible for them to support mixing and matching of binary and custom compiled applications.

Sabayon does it's very best to put cutting, if not bleeding edge packages in entropy while still attempting to maintain stability. I realize that for some people, Sabayon doesn't push out new packages as quickly as other distros. But Sabayon does tend to push out newer kernels and modules faster than most distros.

As far as deprecating portage goes, Sabayon has no plans on that, considering entropy is built on top of it.

I realize I rambled a bit, but I can tell you have a good understanding of portage and that you understand there are risks between mixing a binary and custom compiled system. However, Sabayon devs are only in control of Entropy. So all we can do is try and get entropy to play nice with portage. We don't really have the power to make portage play nicer with entropy. If we did, I could certainly envision a way to update all your entropy packages, then go back and update all of your portage packages, but as it stands I don't see that happening. There simply isn't enough people that use the system in this manner.

[King_DuckZ]

Hey, thanks for the exhaustive reply. I'll do the request, having it in equo would be very helpful indeed.

Otherwise one package that I like to build with custom flags is urxvt. It's not a dependency to anything as far as I know, so I don't think that altering its flags is dangerous. For other softwares it's just playing around, but in general I like the idea that I can rebuild something with a custom flag if the binary version doesn't provide it (and if it's worth the effort/risk) - after all isn't this the principle of Linux? So yeah, good thing that portage is going to stay!

About keeping up with portage, I think with the right amount of work it would be possible. Suppose a package maintainer releases a binary requiring libA to have - well - flag A set. Sadly, I'm mixing the repos and I built libA without that flag, so if equo just installs the new package it will be broken from the very beginning. The problem is - how does equo detect this problem? It knows what it needs from the metadata in the package, but it doesn't know what it has. package.use might be out of date, make.conf comes into play and likely other things that I don't know. I see two solutions then:

1) assume that package.use (and his friends) is always valid. Equo could be equipped with a new switch telling that it should pull the binary from the server if use flags are compatible, otherwise invoke portage and pass the hand. The user should be asked before, of course.
The drawback is that you can quickly end up with a system having most of the packages from portage, but you know, the user started it all. You can always get back by restoring the use flags, then equo would fetch the binary and put everything back to normal.

2) make portage keep track of what it did. It did build libA, so at a given moment package.use was certainly valid and portage had all the necessary info that equo is lacking later. I assume that portage doesn't keep track of such a thing, or an option like --newuse would be unneeded.
If such an information was available, equo would always know if it was breaking something and could refuse to update/install or take some other action.
The drawback is that you would need to fork portage, but still maintain it in a shape that allows merging from the mainstream.

In both cases the central point is giving equo the knowledge of what you exactly have on the system. It's not easy and I certainly don't fully understand the complete system, so maybe what I said is just not doable in practice.
That said, I'll just unmask the packages I took from portage for fun, ask for EkoPath and update manually the ones I want to keep

[BlackNoxis]

So King_DuckZ, basically you want to do the same thing as me, but don't do it that right . Let me show you how I do it to keep my flags and recompile (stick with Portage) the next binary update to that package. I .mask in /etc/entropy/packages/packages.mask everything I compile to the current version of Entropy, in this way : http://pastebin.sabayon.org/pastie/8365 (don't bother understand why I compiled some of them, neither do I understand).
Practically everytime entropy tells me there are new updates to some packages, I first search which packages are compiled by me and must be maintained by re-emerging the new version of that package source (the new version of the binary package entropy will tell me, although I will not upgrade it using entropy, I will emerge it with my sets). After I search which packages must remain as I want, I upgrade with equo only those that should be handled by entropy, and the rest, re-emerge the new version. Simple as that

But there is an even more interesting option for this : on a 2nd machine, create yourself a repository with packages recompiled with your specific flags, options, etc., make some scripts to recompile the new packages and create binary packs, link the main machine to that machine and just upgrade via entropy (it will pull in from those repos the packages with the options you want to have). This is ok too