Re: Choosing between .deb and .rpm as an interim package solution
On Thu, 25 Jun 1998, Gordon Matzigkeit wrote:
> I would greatly appreciate your patience, and thoughtful answers to my
> questions. I want to find ways in which my work will be of maximum
> benefit to the APT team.
Your project sounds most interesting, I'd love to help in any way I can!
> I am knowledgeable in building RPMs, and I know that the descriptions
> are simpler (if not as functional), so they were my first preference.
> Now I see that the APT/Deity interface will blow the pants off RPM in
> the long run. I see that pkglib has all the infrastructure one would
> need in order to add seamless support for the Hurd's (vapourware)
> native package administration system.
I know alot about .DEB's but very little about RPMs so I can't really
give you much information directly. But I can tell you what you need to
find out (what I need to find out to..)
Right now APT works exclusively in what I would call the Package
Specification Domain. That is it understand ONLY specifications of
packages. Things that define the name of the package, it's
inter-relations, etc etc. It could care less if the package is stored in
.rpm, .deb or .tar
What we need to discover is if the RPM information stored within the .RPM
file is direclty mappable into the information that debian stores in a
Packages file (like http://llug.sep.bnl.gov/debian/hamm/hamm/binary-i386/Packages.gz)
If this is so, and it can be done without any loss of information then
it's possible to adapt APT to like RPM's -very- easially. I once looked
for an equivilant to Debian's Packages.gz file on RedHat's ftp server but
didn't find any :<
> In your pkglib classgraph, I expect the Hurd will add an
> `Admin/HurdAdmin' object, but not a corresponding
> `PackageFile/PackageHurdFile', until HurdAdmin works well with all the
> existing package formats. HurdAdmin will aggressively use the Hurd
> translator concept (alternate filesystem views), which will be more
> flexible and dynamic than the existing monolithic database approach
> that both dpkg and rpm take.
I'm sorry you read that text, it is very dated and turned out to not
reflect relaity so well. Most of the concepts in there are not necessary
for APT's function and though the 'prototypes' are in place I consider
them obsolete and intend to remove them all eventually.
You might want to read the other documents at
http://www.debian.org/~jgg/deity (also in the source code) that describe
the actual implemented constructs. Some of them do have some revisions
pending but nothing to deviant from the basic priniple.
>From your above paragraph it sounds like you are interested in making
extensive modifications to what I dubbed the 'Admin Directory' I am not
familiar with RPM's implementation of this concept - what information they
store and so on (do you know?)
If you do intend to redo this then major modifications would be called for
from either system. I'd take a look at which -FORMAT- allows you a cleaner
end result.
Also a consideration would be which packages (as in their contents) are
more suited to your needs. It may well be that Debian's development model
has produced packages which are already very usefull to you - then again
RedHat's might have.
> But for now, I have to make a choice as to whether I base my work on
> modifying existing Linux .deb or .rpm packages. I need the help of
> somebody who is knowledgeable in dpkg and its future directions in
> order to make that decision.
Well if you have some specific questions about dpkg and the .deb format I
can answer them, there is alot to say so I'll just leave this open for
now.
> dependencies, conflict resolution, etc)? If not, then what support
> does .deb have for conditional descriptions?
>
> With RPM package descriptions, I can do:
>
> %ifos GNU
> [hurd-specific package description parameters]...
> %else
> [linux-specific package description parameters]...
> %endif
>
> This makes it possible for me to merge my Hurd changes back into the
> original SPECS without compromising the stability of other platforms,
> which relieves me of a heavy maintainance burden.
I think that RedHat has a more expressive source format, I seem to recall
reading that you could selectively apply diffs and other things to the
source. As far as the building goes I think you'll find that debian (esp
with tools like debmake) becomes much simpler and uniform than rpm can
be.
Basically, you can apply conditions like that to the build process but not
to the unpacking process. All source is created from a single upstream tar
file and a single diff file.
> Besides the technical questions above, my the main issue is: ``Given
> that APT will rule the package-management scene, how will my use of
> .deb or .rpm affect APT's relationship to the Hurd?''
That entirely depends how expressive RPM's package descriptions are - I
can't answer that without some sort of guide as to what is in the RPM
file. Is the full spec available someplace?
Personally from your email I think the simplest thing to do is for you to
spend a week looking at making APT understand RPM - don't code anything
just find out if you think it's worth while. Read
http://www.debian.org/~jgg/deity/cache.html - if everything relevent in an
RPM can be represented in those structures then you're fine.
My biggest worry is that RPM might have implemented something foolish that
makes it impossible to use with any APT like tool. For instance I noticed
on their web pages that they have a system where a package can depend on
'files' - this is something a pre-installation tool can never support, the
information simply doesn't exist.
I'm pretty sure that making APT unpack RPMs using librpm would be
close to trivial (unless librpm is limiting somehow)
Thanks,
Jason
--
To UNSUBSCRIBE, email to deity-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: