[WBEL-users] Re: RPM Gui?

Joe Brouhard jbrouhard@kcosc.com
Mon, 12 Apr 2004 13:38:38 -0500 (CDT)


>
> Do they "search", or do they look at the location defined in the ports as
> having the source?  The source defined by the official port
> maintainer...no maintainer, no port.
>

They look at the defined location, and the Makefile also specifies any
dependencies needed.  These dependencies are solved via each package's own
Makefile on the ports tree.

>> Personally, i feel  its a MUCH more efficient and controllable system
>> then any of the current linux package managers has..
>
> IIRC, the *BSD ports tree is just a bunch of Make files and patches, that
> have been created by the port maintainer (sound familiar).  I don't see a
> significant difference from using a SPEC file and patches from an RPM
> package maintainer.
>

Actually, it's a slight bit different.  SPEC files allow you to build
binary RPMs.  The *BSD ports tree and Gentoo Portage build EVERYTHING from
source.  There is nothing 'binary' about it.

The SPEC file is not quite as complicated as the BSD ports or Gentoo
Portage's .ebuilds tho

> My understand of Gentoo is that it does things similar to the *BSD ports,
> but again, it still requires someone to create the "package" before you
> can compile and install it using the distro tools.
>

There's no "package"... Period.  At all.  I run Gentoo Linux at home and
on a production server... and there are *NO* Packages.  Nothing binary. 
Everything about Gentoo is to build from the source.  No exceptions.  The
.ebuild is nothing more than a set of instructions, much like the SPEC
file of RPMs, on how portage is to build this product.

> Having a large collection of software is different then going and grabbing
> random tarballs from the Internet and automagically installing them.
>

I'll have to agree here.  However, the ports and Portage system have a
major advantage over RPMs - complete reverse dependency support.  yes, it
creates a management nightmare on whoever managed the trees, however it
does create a complete repository, whereas RPMs cannot do this very well.

Besides, here's some food for thought.. anyone ever wonder how many
gigabytes it'd take to have a repository of *EVERY* and *ALL* programs
available on the internet???  I'm refering to source tarballs, not binary
packages...

-- 
Joe Brouhard
Chief of Information Services
Kansas City Open Source Consultants
jbrouhard@kcosc.com