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 [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
