[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: on forming a new Linux Distribution



Jason Gunthorpe <jgg@gpu.srv.ualberta.ca> writes:

> On Wed, 29 Apr 1998, Bruce Perens wrote:

> As I see it there are two major problems that preclude using APT with RPM
> as it stands,
>   1 - They don't actually have package dependencies. They have
>       dependencies on files - big difference.
>   2 - They seem to lack a well formed index file, I couldn't find any
>       rpm index on their ftp site.

They have _both_ package dependencies and file dependencies.  In fact,
earlier versions of RPM only had the package dependencies (e.g. Red
Hat 4.2).  I know, I've recently made .rpms of "texk" which had
package dependencies.  (I wanted pdftex.)

The file dependencies are automatically generated, and they are used
for shared libraries and binaries needed by install scripts.

> I took a -VERY- quick look some time ago, at first glance everything else
> seemed about on par with dpkg. But if they are true, those are two very
> major problems.

The only real problems that I see are:

  1. no alternatives or diversions mechanism
  2. some problems with default configuration file handling

I believe I know how #2 can be handled with a small patch to RPM
(changing one constant), and for other problems the developers are
very active and open to suggestions.

> It might be smart to fork rpm (call it something else) and re-do the
> header fields to be more sensible, then use APT to provide understanding

This would be bad.  Especially since RPM is a cross platform standard:
people are using rpm to install packages on Solaris machines and many
other commercial Unix platforms.

> of the fields and use librpm for the actuall installing. Then you get all
> the benifits of Debian's dependency system and the benifits of APT's
> ordering sequencer, dependency engine, multi-source handing, (and
> someday it's GUI too).

> If #1 is really true there is zero point in making APT understand RPM,
> 90% of it's functionality would have to be disabled.

It's not true.


Steve
dunham@cps.msu.edu



--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org


Reply to: