From: Dan Armak <ermak@netvision.net.il>
To: gentoo-dev@cvs.gentoo.org
Subject: Re: [gentoo-dev] Linux Standard Base
Date: Tue Jul 10 04:39:02 2001 [thread overview]
Message-ID: <01071013373600.00550@localhost> (raw)
In-Reply-To: <20010710000006.I29013@cvs.gentoo.org>
On Tuesday 10 July 2001 09:00, you wrote:
> On Tue, Jul 10, 2001 at 08:52:13AM +0300, Dan Armak wrote:
> > I still don't think this should ever be done. Can anyone give me an
> > example of a situation where installing an RPM is better than all the
> > alternatives?
>
> For binary CDs of commercial software, RPM version 3 is the most
> widely-accepted packaging format. So it makes sense for a lot of people
> making binaries for Linux, I suppose. The Amiga SDK uses RPM to install.
It may make sense for them, because they only have to create one standard
version of their CD. It doesn't for the end-recipients, who may or may not
have RPM-based systems.
I agree that _some_ sort of standard binary package distribution is needed in
som situations. However, RPM is very unsuitable for this. It has its own
dependency implementation, and because different distributions and even
different versions of the same distribution need different RPMs for some
reason, this dependency system cannot become universal. A SuSE RPM doesn't
always work on Redhat, even though both distros are completely RPM-based and
may run exactly the same software.
Each distro has its own dependency database. The only really suitable kind of
binary package is a simple tarball, to be extracted either at / or the
install location (i.e. /usr). The local dependency system (Portage, RPM,
whatever) can then generate MD% checksus and filelists and whatever else it
may want. Such a package would either be self-contained (static) or be
accompanied by the required libs in the same manner. In any case RPMs can't
be used because they depend on other RPMs and have a complex system of
virtual provides.
In any case a binary distribution can never be as flexible and (above all)
'standard' as a source distribution. And if the 'commercial vendors' aren't
satisfied, they can go open source.
(I like to write long letters :-)
Dan
prev parent reply other threads:[~2001-07-10 10:38 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-07-09 10:37 [gentoo-dev] Linux Standard Base Luis Ortega
2001-07-09 11:49 ` Dan Armak
2001-07-09 13:26 ` Terje Kvernes
2001-07-09 23:56 ` Dan Armak
2001-07-10 0:11 ` Daniel Robbins
2001-07-10 0:21 ` Jerry A!
2001-07-10 5:29 ` Dan Armak
2001-07-10 10:53 ` Daniel Robbins
2001-07-10 13:21 ` tadpol
2001-07-09 13:57 ` Daniel Robbins
2001-07-09 23:56 ` Dan Armak
2001-07-10 0:01 ` Daniel Robbins
2001-07-10 4:39 ` Dan Armak [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=01071013373600.00550@localhost \
--to=ermak@netvision.net.il \
--cc=gentoo-dev@cvs.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox