Platforms other than Linux?
It is a design goal for the debian packaging system, albeit a long-term
one, for it to work on systems other than Linux, according to discussions
which I've had with other debian folk and according to the project's
documentation. I think, though, that it might be profitable if some
thought were given to this prospect.
I offer as an example my own systems at work. We have a farm of solaris
boxen, which farm soon shall include a number of Digital Unix boxes
as well. We run a lot of custom software, and additionally install tons
of software (GNU, kerberos) which is not packaged by the vendor.
This presents all sorts of challenges in the absence of a uniform
package-manegement solution. Version skew, clean upgrades, and more
are problems, especially as the number of servers grows.
The answer is obvious: dpkg. Yet dpkg is not, today at least, even close
to being able to handle this situation. Sure, versioning, upgrades and
the rest are a piece of cake. I've even gotten the debian utils compiled
and working on Digital Unix. The problem is that, unless I install gnu
libc and all the rest on these machines, dependencies absolutely kill me.
I've got to force each and every installation, which might or might not
gloss over any real dependency problems.
There are a few possible solutions to this problem, but none of them is
obviously superior to the others. Here are some which I see as plausible:
1) For each platform (DU, Slowaris), compile a list of debian packages
for which the equivalent is shipped on the stock platform. Of course,
this list would need to be maintained and would vary from one platform
to another. Do I have Solstice installed? If not, then some headers
might be missing. The degree of overlap here will also not be perfect,
leading to problems.
1a) Build a minimal list of packages which a given vendor's unix supports
on all configurations. Anything beyond this from the vendor is ignored.
2) Most modern unices have some sort of packaging system, although all of
them pale in comparison to debian. (And to redhat as well; the rumour mill
says that SGI is considering switching to Redhat for package management
under IRIX. But I digress.) For each one, utilities could be written
to translate between them and dpkg format for dependency calculations,
etc. Again, the calculation of dependencies will be muddled by the
imperfect overlap between these packages and debian's packages.
3) Build debian-style systems on top of other kernels. This is so
mind-numbingly labor intensive and low-return that it is implausible
for the foreseeable future.
4) Build some sort of dependency-blind version of dpkg et al., allowing me
to install my handy-dandy Digital Unix version of MIT Kerberos everywhere
cleanly without dpkg whining that I've got no libc on the machine.
This approach is really no different than the normal untar-and-run way
in which package management (doesn't) happen on normal unices, and
therefore isn't as unpaletable as it would first appear. One gets many
of the advanteges which debian offers without in any way being worse
off than before.
I am leaning towards option #4 for our in-house use, but I would enjoy
hearing what others think on this issue. I can't imagine that I'm
the only one with this problem, but I've thought that and been wrong
before. If there's already debian-community-conventional-wisdom on the
topic, then a simple URL-cum-note-to-take-it-somewhere-else will do.
--
Todd Graham Lewis Manager of Web Engineering MindSpring Enterprises
(800) 719-4664, x2804 Linux! tlewis@mindspring.net
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: