Slashdot Mirror
Jordan Hubbard On Next-Generation Packaging
GlobalEcho writes: "Developers associated with Darwin are beginning to think about package management and source building. At issue is whether something like dpkg, RPM or *BSD's ports could suffice, or whether they are all just way too mid-90's. Jordan Hubbard himself (now of Apple) weighed in with his opinions (user and passwd 'archives'). Apparently he thinks it is time for something more advanced, and he gives some ideas about what that might look like. Does anyone else have good ideas?"
If I'm not mistaken the whole Ports thing was one of Jordans great inventions. It's succeeded quite well using standard distributed tools (ie. makefiles, compilers, and the like).
Perhaps I'm wrong. Nice to see he's still having great thoughts. Hope whatever packaging system they come up with is portable enough to work on a large chunk of systems (linux in various configs, bsd's, solaris, darwin, etc.).
Rod Taylor
We use a simple XML file-based (i.e., you can edit everything with vi) object-oriented database. The project isn't just about package management, but we implemented a full multi-platform build-from-source-and-install-sitewide package management tool. It also handles dependencies etc.
None of these ideas are new. We at the OpenPackages project have already discussed these ideas and more. We have a pretty solid plan, but unfortunately no one seems to have the time to turn the proposals into a design document and get going. Like Jordan said in his post and i said in my follow-up, time is the critical issue. This is a big job.
t p://openpackages.org/pipermail/op-tech/2001-Apr il/000764.html/ op-tech/2001-May /000826.htmlp -tech/2001-Dec ember/001454.html
Here are some references i included in my darwin-devel post:
http://openpackages.org/html/pkg_design.php
ht
http://openpackages.org/pipermail
http://openpackages.org/pipermail/o
Check out the fink project
http://fink.sourceforge.net/
600+ OS X ports so far, automatic updates,
database indexing, built on top of dpkg.
dpkg is nice, and I have not found it to be as dangerous or as buggy as you, though I have not delved deep in the details. I have been running Debian testing and so far have never managed to do anything awful to it (though maybe I can just count myself lucky). Design aside, it has a fatal flaw which is the licensing. Since it is GPL, Apple has to be cautious about it. While personally I doubt that there really is an issue with infecting the whole system, since NeXT and Apple have both suffered the wrath of the FSF's attacks (FSF sued Next over not releaing ObjC changes to gcc, and Stallmans rants about porting GNU software to A/UX seemed downright hostile) I can see why their lawyers are cautious. Plus Apple has a lot of IP on the line that they really do need to protect, since they could get sued by their shareholders, even if legal did not balk.
BTW - You can actually use dpkg already with Mac OS X by installing fink though it is an external project. It works well, has a fair number of packages. I use it and highly recommend it.
Hyperbole is the worst thing ever.
The username/pass are mentioned in the story. :-)
The dependency and dependency resolution system- dpkg has the most advanced dependency system known to unix. No dobut to that... To solve these dependencies, dpkg goes to it's list of package locations (complete with http and ftp locations, cdroms, etc.. if necessary) and grabs the required packages from the net (the user is prompted on this, of course)
Dpkg doesn't do that. APT does. Its not that these aren't great and massively useful features, its just that just like urpmi, APT works its magic across RPM (the LSB standard packaging system, which many app packagers primarily package for) too. I maintain an apt repository for my workplace with around 3000 packages, all in RPM format for Red Hat 7.2, and it works like a charm. Debian's policies are postable too - Connectiva has a similar set of guidelines. The unique advantages of Dpkg is suggested / recommended dependencies, something RPM desperately needs (Red Hat themselves cheat and use the `comps' file to provide this logic themselves in the installer, but us users don't have the luxury). RPM has some unique advantages too tho - transaction handling in the database (thanks to DB3) does wonders for my piece of mind. In the end, I'll stick with RPM and Apt-get because of the LSB stuff, and avaliability, but I do hope they add suggested / recommended dependencies soon.
Actually, if you want to see a system which kicks both their arse in many ways, look at QNX. They have apt-like features, a nifty `package filesystem', and a GUI installer that reallycraps all over every other software install system I've ever seen.