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?"
Quite frankly, dpkg isn't all that bad. It has MAJOR issues; no dobut about that, but has many great concepts which can't be found anywhere else (correct me if i'm wrong. they're still good ideas, though!)
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)
--Easy upgrades. No other system allows me to bring my system up to date in less time (note: debian isn't updated often, so this is generally unappreciated)
$apt-get update
$apt-get upgrade
(hit y to confirm)
All from the command prompt.
I'm not sure what else there is that makes it good. But RPM certainly doesn't have these features.
What it lacks:
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)
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.
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.
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
i dunno what i forgot?
-- If you try to fail and succeed, which have you done? - Uli's moose
Gentoo Linux is aiming to create a much enhanced collection system.
Many unix users seem to think existing solutions are great. You know, I've taken to Cocoa since I got my Mac last month, but there is one thing that drives me crazy and thats figuring out this freaking package manager. Its not easy for people use to using Windows Setup or other installation packages for Windows development tools.
The problem is UNIX isn't designed for the average user. When you look at it from a Unix perspective, it works great. When you look at the rest of the world, it doesnt. And anything thats a single platform does not create a big issue. You won't see it used on all your open-source console apps, mainly MacOS X applications. This is definately needed in Mac OS X.
www.atacomm.com - The Leader in VoIP Product Distributi
Hurbbard states :) for any number of potentially
"1. All the descriptive text which current goes into a Makefile like the
port's name, version, dependencies, URL for source bits, and so on,
should go into an XML file. This immediately allows the port to be
indexed, documented and modified from automated tools which traverse the
"ports collection" (sorry, I have to keep using that terminology since
it's what I'm most familiar with
interesting reasons. The reason a lot of these tools don't exist for
*BSD today is that extracting data from Makefiles generally sucks from a
parsing perspective so people aren't encouraged to get too creative."
To reprase.
Metadata should be in XML, this makes it much easier to process than if it has to be extracted from Makefiles
But why does it have to be XML (or SGML or RDF for that matter). The only reason i can think of is that there are pre-existing tools to parse it, the tradeoff is that any Markup language will bloat your metadata and make it unreadable.
Shouldnt a packaging system be important enough to warrant the development of its own parsing routines. i.e. just design it to be the best it can be