Hi! I realize that this e-mail may sound like I haven't done my homework, but the reality is that I am interested in your personal opinions on this issue, which goes far beyond the technological side of things, and is hard for me to learn just by reading source code.
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. I am currently working on putting together an installation system for the next GNU/Hurd binary release. I desparately need a package management system, and I see that .rpm and .deb are the main options. 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. 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. 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. If I sink my time into RPM-style packages, will people be able to use them under APT? Not only that, but will the APT interface to .rpm packages be just as functional as RPM's native interface (i.e. package 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. 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?'' If I choose .rpm, and APT doesn't provide complete support for .rpm for a long time (if ever), then I'll have made a bad choice because the Hurd package descriptions will need to be completely rewritten into the new format in order for the Hurd to use APT. On the other hand, if I choose .deb, and APT soon supports .rpm, then I'll have wasted time struggling to learn .deb, when I have more important tasks to do. I hope that this e-mail makes my situation clear to you, and that you can help me find a satisfactory solution that will pave the way for full cooperation between the APT and Hurd teams. If you have questions about any parts of this e-mail, please don't hesitate to ask me. Thanks, --Gord -- I left my .signature at home. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
