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