stable-testing..unstable?...what's the difference?

[_mic_]

hi everyone,

i've been running 4.1 for 10 days and trying to understand it as much as i can.
i really like the "resources for you" in the newby area...very usefull. i've been trying to be more familiar with package managing, configuration files when updating and, above all, with the make.conf.

i have a little question for you all:
i've seen that on sabayon,the default in the make.conf is ACCEPT_KEYWORDS="~x86" (testing...right?).

what i don't understand is:
is there a "stable" sabayon?
coming from debian, before they froze lenny, i was running it as testing and in my sources.list i had "testing" not the name of the release. this made my switch to squeeze automatic, without any upgrade.
when i downloaded the sabayon iso, i took the 4.1 assuming that that was stable (there was no mention about it's state of development)....but i'm running testing, right?

in this case, according to the road map http://www.sabayonlinux.org/pages/show/id/80/0 what's gonna happen on june 3rd, 4th or whatever those date will be? will the daily update of my system update the version i'm running? is it kind of the debian situation?...i'm confused.

sorry about this post, this is not really a "problem" (so far i'm happy about my system) but just a curiosity.

thanks,
mic

[Fitzcarraldo]

Regarding the stable/testing issue, Sabayon Linux is customised Gentoo Linux, so you might find the explanation in Chapter 3 of the Gentoo Handbook of help. There used to be a stable edition of Sabayon Linux (it was called "Professional Edition", and, before that, "Business Edition") but it is no longer available or supported. Many Gentoo users set the arch in make.conf to pull in test packages, just as SL does. Only some Gentoo users -- such as server admins -- stick to the stable branch. In fact, as a quick look through the Gentoo forums and Gentoo Bugzilla will show, many Gentoo users are at a more bleeding edge than SL, if you catch my drift.

Both the Gentoo (and therfore SL) source code package manager Portage, and SL's very own binary package manager Entropy, allow the user to keep the installation ('world') up to date: the so-called 'rolling release' system. Regarding Entropy updates, I'll let one of the Entropy experts fill you in, but basically you can perform rolling updates to the branch currently specified in your /etc/entropy/repositories.conf file. If you want to change to a different branch (let's say 3.5 to 4, 4 to 5, or whatever) then you would edit that conf file and do an equo update and world update (see, e.g. viewtopic.php?f=76&t=16136 and viewtopic.php?f=5&t=16152). So, if you don't change your branch, updates are for that branch. Anyway, I olny use Entropy occasionally, so I'll leave the experts to provide you with more details.

[_mic_]

thanks for the info Fitzcarraldo

Sabayon Linux is customised Gentoo Linux, so you might find the explanation in Chapter 3 of the Gentoo Handbook of help.

i'd found this and read it but i was still a bit confused.

Both the Gentoo (and therfore SL) source code
package manager Portage, and SL's very own binary package manager Entropy, allow the user to keep the installation ('world') up to date: the so-called 'rolling release' system...[..] Anyway, I olny use Entropy occasionally....

so basically the upgrade can be done following both routes (and you are for the portage one). Somewhere in this forum i read that using only portage would kind of annihilate the sabayon existence given the "binary" nature of the latter.

can a user run sababyon using only entropy (equo+spritz)? (indeed, having an understanding of how portage works)

if i can compile and install a package from source myself (for instance im a GIS user and i will probably be doing this for GRASS), what's the meaning of having them both? only more flexibility, or is it theirs an indissoluble relationship?

cheers,
mic

[Fitzcarraldo]

The essence of the two methods of package management can be summarised as follows:

With Portage, the Gentoo repository maintainers create scripts of commands in text files called 'ebuilds', which are stored in a repository and are downloaded automatically to your HDD when you issue a 'synchronise' command. You either use the emerge command from the command line or a third-party GUI (Portato is one example) to execute an ebuild script in order to install an application. The ebuild takes care of downloading the source code, all associated files required (even binary files, in the case of some ebuilds), checking dependencies (i.e. what libraries and other applications, if any, are also required), performing various other tasks, and then compiles the application and installs it and any associated files in the correct directories on your HDD.

The Entropy repository maintainers use Portage to compile ('build') the packages from source code, i.e. they use Portage to create the binary packages. Then they put these binary packages in the Entropy repository. Then you either use the equo command from the command line, or the Spritz GUI, to download from the repository and install the package and any associated files in the correct directories on your HDD. Entropy knows what packages are available and their versions after you issue an 'update' command to update its database on your HDD. Entropy was conceived by the developer of Sabayon Linux, and he developed the equo and Spritz tools. Similarly to Portage, Equo/Spritz will check all the dependencies and install any additional required packages.

In summary, with Portage you compile the package and install it and any other required files. With Entropy you download the pre-built package and install it and any other required files. In each case, the Portage and Entropy package managers automate the process and perform a lot of checks too.

So you can choose which of the two package managers you want to use. But there are a few caveats...

The Portage package manager allows the use of 'switches'/parameters which allow you to turn on or off certain options when you compile a package. To give a hypothetical example, you may want to compile a multimedia application to rip DVDs to the Matroska file format (assuming, of course, the application developer has included this facility in his application), or you may have no interest in that media format and decide you want to compile the application only to rip DVDs to the AVI file format, which may make the application occupy less space on your HDD and perhaps run a bit faster. These 'switches' in Portage (called 'USE flags') allow you to do this when you issue the emerge command. As the Entropy packages are already compiled with a 'standard' set of USE flags decided for you by the Entropy repository maintainer, you have to accept what you get.

Now, in the vast majority of cases this is fine, because what you get does what you want. Occasionally, however, you may want a feature in an application that is not available in the Entropy package. It's in that situation that you would need to resort to using Portage. As a perfect example of this, see the article in the SL Wiki on the PyKaraoke package: the sdl-mixer package from the Entropy repository had been built without the USE flags required for using sdl-mixer with the PyKaraoke package, so an Entropy user would need to resort to using the Portage package manager to rebuild the sdl-mixer package with the needed USE flags. If you read the aforementioned article, it should be reasonably obvious what I mean.

So Entropy gives the user convenience (pre-built packages) and speed (you don't need to wait for ages while the source code of a mammoth application is compiled on your PC). If you were to use Portage to install OpenOffice, you would find that it takes 6 or so hours to build, whereas Entropy will download and install the binary files in a fraction of that time. In fairness I should point out that a few ebuilds in Portage download pre-compiled packages too, and openoffice-bin is one of them, so even a Portage user who does not fancy waiting 6 hours for OpenOffice to compile could install the pre-compiled package within Portage. But the vast majority of ebuilds build applications from the source code.

The Entropy repository has a sub-set of the packages in Portage, so occasionally you may find you want a package that is not available in the Entropy repository but may well be available via Portage. Even if an ebuild is not available in the official Gentoo ebuild repositories, there are many third-party repositories of ebuilds (called 'overlays') that have ebuilds of packages not available in the Gentoo Portage repositories (plus, in some cases, customised versions of ebuilds in the main Portage repositories). Some of the packages in Sabayon Linux are in an overlay (called -- surprise, surprise -- "sabayon"). And Portage even allows you -- if you know how (which is not trivial) -- to use your own home-made ebuilds in a 'local' overlay on your HDD.

One advantage of Entropy over Portage is that all the pre-built packages have been compiled in a controlled environment with the correct libraries and other files present, so they are more likely to work. Also, where necessary, Entropy packages are tied to specific versions of the Linux kernel if they have to be used only with that version of the kernel. Unless you know what you're doing with Portage, after installing, updating and deleting various packages on your HDD it is easier to end up with missing dependencies or inconsistent versions which make it impossible to compile another package you now want to install.

Bottom line: Generally speaking, Entropy is easier to use than Portage, albeit less flexible (which is not an issue in 99.9% of cases). It is also more 'robust' than Portage in the sense that it is more difficult (but not impossible) to break your installation by installing, upgrading or deleting packages.

Furthermore, if you think about it, there can be situations where you want to install package A from Entropy that requires an earlier version of a library or package B than that required by package C which you installed via Portage, and Entropy will try and downgrade package C back to the version that Entropy installed. I hope I'm making sense? So this can cause problems if you mix the use of both package managers. There are ways of forcing Entropy not to do this, as you will discover reading the forums and Wiki articles.

Thus, unless you are reasonably familiar with Gentoo, you are better sticking with Entropy. The general advice by others in the SL forums has been to choose a package manager and stick to it. If there isn't a package in Entropy that you want, you can request that it be added to the Entropy repository (see Requesting Packages for Entropy - New Policy) and, if you need it urgently, use Portage.

In Linux magazines and on many Web sites you'll come across instructions on how to compile applications yourself manually, i.e. without the use of a package manager. This should only be done as a last resort. Package managers were created for a reason. Apart from the obvious advantage of simplifying the installation process, they check that the files they download are not corrupt, they download the correct versions of files, they take into account the environment on your PC, they check for dependencies, they download and install other packages required by the one you're installing, they check to see if they are going to overwrite other applications' files, they uninstall an earlier version from your HDD, they clean up afterwards, and various other tasks.

I use Portage mainly because I'm used to it -- Entropy is relatively new on the scene -- and because, for my requirements, I find the total flexibility useful sometimes; for example you'll find a few threads of mine regarding local ebuilds for packages I have wanted that were not in any Portage ebuild repository or overlay (or in Entropy). However Entropy is the package manager of choice on a laptop that I set up for one of my children, because it's faster and easier to use than Portage, thus simplifying the very infrequent maintenance I perform on it, and my offspring find Spritz simple enough to use. Basically, it's robust enough for someone who is not an expert. There is no way I'd want to inflict Portage -- even with one of its third-party GUIs -- on a newcomer to Linux.

You can read in more depth about both Portage and Entropy in the SL Wiki, and there are many threads on the subject of Entropy vs. Portage in the SL forums. Also see the Resources For You thread and other 'stickied' threads. If you are a newcomer, then you have to do some reading: no pain, no gain. I've glossed over a lot of detail in the above explanation, but hopefully it gives you a rough idea of the concepts.


EDIT: The Spritz GUI has now been renamed 'Sulfur'.

[_mic_]

MAN Fitzcarraldo! This was a very well detailed explanation...THANKS!

I think I'll stick with equo and spritz for a while then! (btw...why Spritz and not Negroni? a bit stronger, but still a nice "aperitivo" ...just kidding, I'm from Tuscany).

Thanks again and I'll catch you around...I like Sabayon...very interesting system!

See ya,
mic

[ReemZ]

You can read in more depth about both Portage and Entropy in the SL Wiki, and there are many threads on the subject of Entropy vs. Portage in the SL forums. Also see the Resources For You thread and other 'stickied' threads. If you are a newcomer, then you have to do some reading: no pain, no gain. I've glossed over a lot of detail in the above explanation, but hopefully it gives you a rough idea of the concepts.

Actually, I think your post should be added to that Wiki!

btw...why Spritz and not Negroni? a bit stronger, but still a nice "aperitivo"

OK, so Spritz is a drink? Didn't know that
Anyway, thank you for posting about booze on my birthday

[_mic_]

You can read in more depth about both Portage and Entropy in the SL Wiki, and there are many threads on the subject of Entropy vs. Portage in the SL forums. Also see the Resources For You thread and other 'stickied' threads. If you are a newcomer, then you have to do some reading: no pain, no gain. I've glossed over a lot of detail in the above explanation, but hopefully it gives you a rough idea of the concepts.

Actually, I think your post should be added to that Wiki!

btw...why Spritz and not Negroni? a bit stronger, but still a nice "aperitivo"

OK, so Spritz is a drink? Didn't know that
Anyway, thank you for posting about booze on my birthday

always down with the booze http://www.barnonedrinks.com/drinks/a/aperol-spritz-13239.html
or
http://www.drinksmixer.com/drink5060.html....1/3 - 1/3 - 1/3....you cant be wrong
happy birthday

mic

[ReemZ]

always down with the booze http://www.barnonedrinks.com/drinks/a/aperol-spritz-13239.html
or
http://www.drinksmixer.com/drink5060.html....1/3 - 1/3 - 1/3....you cant be wrong
happy birthday

mic

And that bird is FIT! :9
Thanx 4 hb wishes, I did have quite a nice one........................iirc