Choosing between .deb and .rpm as an interim package solution
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 deity-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: