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'.