[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Installing software without a package manager
"Koree A. Smith" <firstname.lastname@example.org> wrote:
> Especially if you're installing source or other versions of
> software that your system's package management already has.
Unfortunately, that conflicts with enterprise configuration
The only limited application of a "ports" approach in a "packages"
distro I've seen are when you need developer-level packages -- e.g.,
Java, Perl, Python, etc... Those are fairly self-contained
sub-systems in a system, but can be reproducable with those tools.
But for software that touches numerous aspects across an entire
filesystem -- I agree with Steve.
My _original_ point still stands -- Sun's RPM hierarchy sucks to the
point that it's just as bad as an installer (unless tamed by the
corresponding jpackage RPM). And with nVidia's good 2D support in
the stock Xorg releases, I typically don't need 3D for desktops.
When I do, I generate the RPM myself (burnt too many times by
Livna.ORG's nVidia driver).
> For example, I have installed spamassassin from source. The
> reason is to keep up with newer versions, as RHEL 3 is horribly
It's not "horribly behind," it's an enterprise distro that undergoes
_no_ "feature" changes once released -- only backports. If you don't
like that, run Fedora Core. It's quite a stable and reliable
I'm planning to upgrade to Fedora Core 5 when it's released from
Fedora Core 3. Just like I did to Fedora Core 3 from Fedora Core 1.
And Fedora Core 1 from Red Hat Linux 9. And Red Hat Linux 9 from Red
Hat Linux 7.3 some 4 or so years ago now.
> but, I can no longer use up2date to update that package,
Huh? Did your subscription expire? If so, then either renew it or
switch to CentOS. But if you're looking for "feature" changes,
you're running the _wrong_ distribution. You want to be running
Fedora Core and upgrading about every 12 months.
Features and stability are very mutually exclusive -- especially when
it comes to a proven, integration-tested distribution. That was one
of the major reasons for the split from a single product line which
was failing to address both (let alone the additional trademark
> and everyone's bayesian filter data is locked into the version I
> have now. It would be a pain to roll it back.
> However, I've installed Undernet ircd from source, and it's not an
> issue. RHEL3 doesn't have an ircd package.
Consider "checkinstall" to generate a RPM. You merely replace it as
your "make install" step when building.
Otherwise, consider CentOS Plus, DAG or other 3rd repositories.
> I would agree that installing drivers or libraries, and not using
> your package management is a bad idea. Unless you *really* know
> what you're doing.
I would argue you should at least use "checkinstall" to generate a
RPM -- saving you a lot of the grief that Steve was mentioning.
> This is just my opinion, of course.
Again, Steve is correct. RPM when you can. Use checkinstall when
you can't. If it's something that's got an installer, learn how to
repackage it into RPM (of which nVidia's driver/GLX _can_ be done).
Bryan J. Smith Professional, Technical Annoyance
*** Speed doesn't kill, difference in speed does ***
To unsubscribe, send email to email@example.com with
"unsubscribe silug-discuss" in the body.