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
Absolutely! sorta.
The G4 differs from the G3 in a lot of piddly little ways, and one great big, huge way. The G4 has the AltiVec engine (a vector computation unit, alongside the Integer and Floating Point Units). However, it's a little specialized and (afaik) there aren't any compilers that automatically generate AltiVec-optimized code. On the other hand, programmers can use AltiVec (vector engine) accellerated functions, which will then be much faster on G4's than on G3's.
As an example of an AltiVec accellerated function, look up the man page for writev(). Basically, it's a vectorized (and thus accellerated) version of write().
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.
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)
Umm, apt that does all that.
(note: debian isn't updated often, so this is generally unappreciated)
Debian is being constantly updated. If you are refering to the 'potato/stable' branch, then it in rarely updated. But 'woody' and 'sid' are being updated very often.
I'm not sure what else there is that makes it good. But RPM certainly doesn't have these features.
There is a version of apt-get for rpms that had recently been released. Not quite at the debian level, but still better than nothing.
It's buggy as hell - it's easier then signing up for aol to nuke your system this way (in other words, it happens quite often by accident)
I've never experienced any bug's in either apt or dpkg, though I've never used the sid/unstable branch. (And if I had used sid/unstable, I would have no right to complain about bugs, just to report them on bugs.debian.org).
No good front-ends - There is no good program to browse available packages, install them, enter configuration information (more on that in a sec) and remove them. You should enter the package you want to install. a wizard is displayed, it grabs the package from a mirror or local source, solves dependecies, installs it and any dependent packages, configures it, and exits.
Aptitude, Deity? What is wrong with them? (Make sure you get them from woody)
Configuration - dpkg has a system that allows the package to prompt for a few options before it is installed. this is a good thing, but the packages usually don't ask enough. users need full customization (nothing nitpicky. big stuff... so you dont have do manually edit configuration files by hand
If every package asked many questions then you would never finish an install. Anyway, debian lets you choose the amount and importance of the questions you are asked. Thats what debconf is all about. And compare it to redhat, where you aren't asked any package specific questions during install.
Available packages - this is where dpkg falls flat on it's face. 95% of unix packages are rpms. that never helps. a unified packaging system needs to be put into place.
Woody has 8602 packages atm. Debian does have a unified packaging system. All packages use the same package format, are found, retrieved, and installed using the same applications, and are kept together in a central location ( ftp.debian.org - and its mirrors). Nothing else compares.
i dunno what i forgot?
I dunno, what other debian fallacies can you think up.