Re: bentley rhodes, attempting to compile lame.

[Bryan J. Smith <b.j.smith@ieee.org>]

Every RPM distro today has a "front-end" for distributed package dependency checking and automatic resolution/download.

Red Hat officially supports UP2DATE which can not only connect to the RHN, but to any APT or YUM repository.
In fact, with Fedora Core, UP2DATE _still_ hits RHN server by default.
But the access is _free_ now!

A separate YUM binary is also is included.
Fedora is moving to YUM-integrated everything, from installer to run-time.
Cobind even has a GUI front-end for it that works well for RHL9+.

Fedora Extras has always offered the best, damn APT-RPM implementation I've ever used.
The second I heard about the Fedora Project, I dropped FreshRPMS.net and started to experience bliss.
Red Hat's decision on who to merge with was a no-brainer.

As with _any_ "packages" distro -
be it Red Hat, Mandrake, SuSE or even DPKG distros like Debian and its commercial off-shoots -
you _must_ be wary of what you "front-end" is connecting to.
You can get Debian's APT "front-end" into just as much "trouble" as any other "packages" distro.
I've had to break-out DPKG commands on many Debian systems where someone was just "adding everything" to their sources.list.

Now "ports" distros (FreeBSD, Gentoo) have
Their advantages.
E.g., Gentoo "portage" only distributes the make/config files.
So they don't run into the issues that Debian, Red Hat, etc... Do with software that has "problematic licenses."
They also build efficient, smaller distros.
E.g., Livna.ORG must build MPlayer for every extension imaginable, whereas Gentoo "portage" will typically only build for the extensions the CPU of the system supports.

But I've yet to see the "optimization" argument hold.
Most "packages" distros build for i486 or i686 these days, and optimize _all_ binaries for i686 (or even P4).
And again, all software capable of extensions are built for all extensions.
In a nutshell, it _always_ comes down to the Makefile,
and a "ports" maintainer has no inherent "speed" advantage over a "packages" maintainer.

Unless, of course, you throw the -O3 gcc switch.
Then "ports" distros deserve what they get -
bad math (on P3/P4) and instability (especially on Athlon).
Hence why "packages" distros ship -O2.
Although anything is just a DPKG or RPM rebuild away
- be it manually or via a front-end like APT, YUM, etc...

-- 
Bryan J. Smith (currently mobile)
b.j.smith@ieee.org

-----Original Message-----
From:  Ray McCord 
Date:  04-12-22 10:45
To:  silug-discuss@silug.org
Subj:  Re: bentley rhodes, attempting to compile lame.

You may have better luck if you try installing an SRPM (source RPM)
and let RPM figure out the dependencies for you. At least you'll know
what SRPMs you will need to have to get this thing compiled correctly.

I use Gentoo, so I don't deal with RPM too much. I am not sure if
Fedora Core has anything in it like Red Hat Updates used to do, so you
may still need to hunt down the actual SRPMs at RPMfind, Pbone, or
some other RPM repository. But, knowing the exact SRPM and version
your source package depends on is better, IMHO, than looking up every
file you run into that is missing or incompatible.

BTW, sent you a gmail invite. I thought you might find it useful after
getting the feeling you had to put some effort into getting Mozilla
Mail to do what you wanted.
That, and I know how Yahoo Mail is. I wouldn't wish Yahoo Mail on anyone. ;)

Cheers,
Ray McCord (since there seems to be another Ray out there using 'Ray' ;)

On Tue, 21 Dec 2004 20:07:30 -0600, bentley_rhodes
<bentley_rhodes@yahoo.com> wrote:
> hi, i was trying to compile LAME, and i started fine through
> ./configure.  Then i tried 'make' and somewhere down the line i ran into
> trouble (errors) with vbrquantize.h.  There as a *.c, but no vbr*.h.  So
> i found one on the net, and tried it, then i recieved errors to
> vbrquantize.lo.
> 
> do i have to look all these up on the net?
> 
> -
> To unsubscribe, send email to majordomo@silug.org with
> "unsubscribe silug-discuss" in the body.
>

-
To unsubscribe, send email to majordomo@silug.org with
"unsubscribe silug-discuss" in the body.

-
To unsubscribe, send email to majordomo@silug.org with
"unsubscribe silug-discuss" in the body.