[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Platforms other than Linux?

Todd Graham Lewis writes:
> 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.

Your other quick fix option which I often have done in the past when packages
have got in a tangle is just to hack the /var/lib/dpkg/status file.
Just put a fake libc entry in.

Famalirise yourself with the status before you change anything in it though :)

> 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.

I kind of like this option. It would only really be needed for the base packages
and some of devel and libs.

> 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.

Dependancies are one of the great strengths of dpkg I find. It is a bit of a hassle
here but I think I like option 1 better than 4 still.

1 isn't all that hard, would just require a few stub packages.

This would be a great project. Everytime I update something on one of our non
linux boxes I wish I had dpkg.


Dehydration - 34%, Recollection of previous evening - 2%, embarrassment
factor - 91%.  Advise repair schedule:- off line for 36 hours, re-boot
startup disk, and replace head - wow, what a night!
                -- Kryten in Red Dwarf `The Last Day'

Andrew Howell
Perth, Western Australia			       andrew@it.net.au

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: