Sabayon Test Tree

[paulkoan]

Hello all,

I have been using Sabayon on my desktop for the past few weeks, and it is great to have a gentoo based desktop rather than good old ubuntu. Especially as my server has been running gentoo for a good while now.

The main problem I have with Sabayon is it drive to always update to the latest test package, even if the current version running is stable. This can make installation of some packages difficult, and emerging world can cause havoc.

I wrote this article to help move an installation of Sabayon away from test packages:

http://www.zencore.com/2007/04/sabayon-stabiliser.html

Though it occurs to me that there would be more noise if this was a problem for many people. So is there another approach to this, or are people just leaving the base install as is?

Thanks,

Paul

[wolfden]

Well one of the biggest draws to SL is it being "bleeding edge" so requests for a stable branch are pretty rare. It's a great idea for anyone interesting in stable branch tho.

[paulkoan]

Yeah for sure.

Having beryl at the latest release is sensible, at least until they move into the tree. There are some elements of the system that I would want to keep at tested packages, rather than testing.

If you do:

Code: Select all

equery -N list | grep \~ | wc -l

You will get a count of the packages that are masked for testing. Mine currently has 852 out of 1348 installed at are at test. I think I would prefer to go the other way, and "let loose" some packages into the test tree and keep others back - particularly some of the system fundamentals.

This approach gives you the option as you can just comment out any packages you don't want held back.

[voxiac]

I'm certainly interested!
I've read you article and I'd just suggest to approach the problem the other way around, i.e. set ACCEPT_KEYWORDS=amd64 in the first place
and than generate the list of the installed packages, which should be marked unstable, i.e. add lines in /etc/portage/package.keywords such as
<=category/installed-package-version ~amd64

or with the same example, as you used:
<=media-video/vlc-0.8.6-r1 ~amd64

Then remove those entries from package.keywords as stable versions superseed the installed unstable ones.

What do you think?

P.S. As a side note: I was very impressed when paludis, after changing ~amd64 to amd64 in keyword.conf file, didn't mind resolving all dependencies to satisfy this change (lots of suggested downgrades). I've never succeded to stabilize my system that way however... There were still build errors, which with lack of --resume --skipfirst magic coudn't be countered in efficient manner.

[paulkoan]

Yes... excellent stuff voxiac

It gets around the problem of testing packages requiring new dependencies - and installing test packages because they are not accounted for, or if you install a new package, having to add a line to stop the testing package being installed.

I should have thought of that - perhaps not at 2am when I was putting it together, but certainly since. I need to have this added on to the article.

Would you like to add a comment to the article so you are credited properly?

I tried the approach of changing the ACCEPTED to non-test packages also, and emerge came up with a install path that supposedly would have gotten to a clean build... but no. After several days of pretty much non-stop compilation, I gave in and accepted that you need to start from a baseline.

[voxiac]

Would you like to add a comment to the article so you are credited properly?

Never mind... I've been thinking about that issue for some time now, it's just your thread and article that triggered something in my mind I suppose . So I've never tried to stabilize the system that way and I would be much more pleased to know whether it works or not .

As for the solution I imagine it could be like running that equery/sed combo of yours (modufied a little) once to setup things initially and then add a script as a cronjob to parse package.keywords and delete the obsolete entries. The last one would be quite a bit of trouble for me (and I certainly wouldn't do it by hand ).

[paulkoan]

Hi voxiac, in case you don't see the post at my blog, here is the new article that turns things around, and puts you into a "stable" position as you suggested:

Stable Sabayon 2

By the way, I tried the "<=" approach, but it becomes difficult to manage where you have multiple versions of the same package installed.

So this time I just used "=". Only the current version installed is an acceptable testing package.

[davemc]

Interesting, but kinda pointless for Sabayon IMO. As you said, Sabayon is all about latest and greatest "bleeding edge" of the bleeding edge, unless you just want a stable Gentoo system without the painful install. I have a base Sabayon 3.4 install going and its rock solid stable thus far -- Most stable system yet in fact, outperforming even the likes of Fiesty Kubuntu on my other system which has been about as unstable as ive ever seen on a Linux distro. I guess it all comes down to the "if it aint broke, dont fix it" mentality, but that goes against the whole Gentoo grain I guess heheh.

[paulkoan]

Yeah absolutely pointless for those who want to remain using testing packages with Sabayon, which I am sure is many people.

I have no doubt that the Sabayon releases are rock solid. That isn't the point. Anything that gets installed afterward that isn't in the base install, and any updates included in "emerge world", will be test packages that aren't necessarily going to be as stable as the packages installed as part of the base.

Inevitably, as time goes by, and world is updated, something will get installed that causes problems.

There are three options:

1) Only install Sabayon releases
2) Accept that things may go wrong
3) Install tested packages


The article was for those who call into catagory 3.

[Darksurf]

Not bad! I don't do fully stable though. Sorry. Even when I used slackware (very very stable and secure!!) I tried running beta applications and what not. I'm a beta addict! I love packages that are labeled "experimental" "testing" and "beta"