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?"
But in practice I just don't see how it's gonna be any different in the long wrong. I mean with the xml you'll be able to do alot more stuff, a simple database etc it starts to get a little bit big for a porting system. How long until this becomes obsolete because the database is too big to search effectively.. I like it but i just think that it's implementation is gonna be the hard part. Then again implementation is always the hard part.
No, the dependency satisfaction and easy installation and upgrading is a feature of apt, a frontend to dpkg, not dpkg.
note: debian isn't updated often, so this is generally unappreciatedNo, if you use the testing or unstable branches, Debian is updated daily. If you stick with stable, the easy downloading and installation is still good for installing new software.
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 disagree. Nothing of this magnitude has ever happened to the systems I've ever administered, and I haven't heard it happen to anyone else. If you use unstable, which means you should be prepared for such occurences, there's the slight possibility of this happening, but that's a problem with the actual software packages, not a problem with dpkg or apt.
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.No, dselect, aptitude, deity, are some of the many frontends to dpkg and apt that allow browsing of packages. When using dselect, for instance, you select the packages you want to install an uninstall and go to "Install". It does exactly what you say it doesn't, it grabs the package from a mirror or local source, grabs dependencies, and installs it and any dependent packages. Then, a debconf configuration screen ("wizard") is brought up, in the interface that you've chosen, such as dialog, Gnome, etc., and you can configure it, or it configures itself dependent on the level of interactivity you told it you wanted before. Then, it 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.The packages ask questions based on the level of interactivity you chose when you configured debconf (or depending on a command-line option when you reconfigure the package). "Big stuff" is what's given to you. If you want to configure everything, editing configuration files is the way to go.
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 placeFrankly, 8600 software packages in one, easily accessible, central repository of stable, well-maintained packages seems a lot to me. Most packages someone would ever want are there, and others, those provided in RPM can be converted by alien to .deb format. Regardless, this has nothing to do with the quality of the packaging format or the packaging tools, so it wouldn't affect this. Any "next-generation" package format would start with no packages, so dpkg beats it at that.
"The price of freedom is eternal vigilance." - Thomas Jefferson
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)
Huh? I suspect user error. I've been using Debian/dpkg since pre 1.0 days, and I can count the number of times dpkg has had system wrecking errors on one hand. I can count the number of times that it actually wrecked my system on one finger -- after that, I got a little more cautious about upgrading dpkg in the unstable tree. (i.e. wait a few hours and read debian-devel), There are ways to tell dpkg to hose your system, but those aren't bugs, those are options with big nasty warnings next to them.
Now, there have been many more occurences of buggy packages screwing things up, but that's hardly dpkg's fault. And if you live on unstable, well, that's what you get.
No good front-ends -
apt-get install aptitude
(Not in stable, but coming soon[1] to a release near you.
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.
Again, not a dpkg issue. If the package doesn't provide sufficient configuration flexibility, it's an issue with the particular package.
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 don't know where you got that statistic. Yes, maybe 95% of packages you see floating around random websites are in rpm, but I doubt that 20 times as many software packages available as rpms vs. debs. Most upstream developers don't provide debs, because there's a debian developer to do so for them; the fact that mozilla.org has rpms but not debs doesn't mean there aren't .debs of Mozilla. (I'll allow that the ratio for non-free software is much worse, for fairly obvious reasons.)
Steve
[1] "soon" in Debian terms, at least :-)
What I would hate to see are any major revisions if it's just gonna add some feature; I would rather see that time spent on developing the ports and packages themselves. Make is a good, simple, foundational and almost always present solution. Adding other languages would be a waste of time IMHO.
Let me condense what I think should be pursued from the ports perspective: documentation and ease of use. One can always make readmes and get mini-descirptions, but that really should be expanded upon, both for beginners and seasoned users who just don't know what that software is about. It would be nice to have some options like, info that would go thought the ports tree and build more verbose information. If those documents are built in a consistant manner (such as xml), then any ol' front end can be built to pull the info on the port and automate building the port and the flavors available. For example, a simple curses interface that will inform you of the dependancies that will need to be built first, estimates the size, and gives you a list of flavors to add into your build. Hit ok and it monitors the progress for you, logs the process and keeps the messages out of sight (from those who get scared easy).
I agree that something should be done to be able to automagically build a package from a port. I think this area would be the best to pursue. Even better, if we bsd types could get a system like checkinstall /installwatch consistantly, not most of the time, but consistantly working on BSD. This project essentially is a wrapper script that records everything make install does. In current form, it gives you the option of building an RPM from that make install. What should be pursued is making this work -well- on bsd, with the option to build a package along with documenting it's dependancies and/or recording the install info into the existing system to that all one has to do to remove what you just built is 'pkg_delete'. THAT would be cool!!
Democrats and Republicans only disagree about how to enslave you
You can wail on about this average user but you must be careful about this cliche. Because the implicit fallacies is that there is an average user of these systems, that they have far less experience than you or I do, and that they aren't already happy with what they are using now. If there is anything more certain that can be said at all about these average computer users is that they probably don't want to change operating systems right now. In fact, not only would there quite possible be no reason for them to switch operating systems right now but it would mean erasing the skills they have learned using the current operating system. Its no coincidence that those who do migrate to other platforms have little to loose. If you think that these so-called average users spend all their time surfing web pages and sending email then there would probably be a lot more migrators to other operating systems.
I think it is useful to consider a few things I learned in a Cultural Geography class last semester. I know these things are pretty much common sense but I think its not only useful to consider these ideas but to introduce some new terms when dealing with these things (rather than using impoverishments like average user). When people migrate from one region of a country to another, they do so for a number of reasons. There are push factors and pull factors.
So why would someone move to a Free operating system? It seems that freedom itself isn't much of pull factor (but this would change, surely, once many of these software laws and licenses are really enforced against end users, not just distributors).
Let me say something about ease-of-use. While it would seem to be an obvious pull factor--the days of easy to use general-purpose operating systems are long over, I think. Perhaps the first Macintoshes were among the easiest systems to use and the reason for this is quite simple. The needs and expectations of users have gone up quite a bit since then. While I have never used these early computers nor do I know the intentions of the Apple staff (these things are probably clearly documented somewhere...I'm too lazy to look right now), I would suspect that they were trying to make as easy as possible to type out documents with relatively sophisticated typessetting (compared to typewriters!) and then to file these documents into a filing system.
Today's systems are expected to require quite a bit more. Many of the posters here on slashdot carrying-on on what these operating systems need to be successful (in what ever definition of success, most do not say) give examples:
The paradox is that this average user needs all of this. This seems extremely unfair to anyone trying to implement an operating system...nowadays to any team of programmers or consortium of developers contributing to an existing free software project.
Now lets consider what relevent about talking about the average user. Like I said before, I doubt this user would switch his or her operating system for any reason. This is because for everyday this user masters his/her OS, the push factor from every other OS becomes stronger and stronger. Unless there exists a push factor from the OS he is currently using, he's gonna stay.
So lets forget this average user since it isn't relevent or even interesting. Lets consider, instead, a different class of users. Lets just create a class of users who might or will definitely switch to another operating system. Now, awaiting to be smacked around with a stack of statistics proclaiming otherwise, I would guess that this set of users would have the following things more or less in common:
And where would you find this average set of OS migrators? Probably on the internet: in newsgroups and web forums. Specifically, you would find that many of these people read and post to slashdot regularly.
And thats the point to this entire post. I find it interesting to hear slashdotters condemn the intelligence of the average users, how they can't program, or they can't figure out the command line. This might be true, but they are revealing their own experiences more than anything else. They are their own breed of software users.
In conclusion, You Are the Average User.
Jordan said "I think 10,000 entries is going to be something of a stretch even for the FreeBSD ports team, but I don't see that number being entirely improbable for some Macintosh equivalent since there are a lot more Macfolk than there are FreeBSD users." This comment tickles at a core problem with the transition from OS9 to OSX for many Mac users. There may be more Macfolk than FreeBSD users, but how many of them want to rethink package utilities? A lot of Jordan's comments are good suggestions (for instance, implementing the new standard of XML into the package process), but it seems that this problem will be tackled by *nix users like himself moving over to the OSX platform, and not by OS9 users delving into *nix for their first time. Still, it IS a good time to rethink things before momentum makes it difficult to change. I also agree with him that Apple should have spearheaded the process, and they probably will in time. Apple has always focused on userfriendlyness first, then streamlined what was under the hood last. Compared to the past, Apple seems to be responsibly balancing the development of OSX across the board. However, if OSX is to succeed with the typical Mac audience, it will need to be a lot more stable and userfriendly to the simplest Mac user. I can't imagine my parents enabling their root account to reconfigure folder permissions as I had to do recently. Heck, my dad can barely figure out his email. LOL, nevermind launch a shell and interface via CLI. I imagine streamlining the package utility mechanism is low on Apple's priorities. Still, it's comforting that Jordan is mulling the problem over.
The Splintered Mind - Overcoming
Hmm. Not to discount fink--I use it myself--but I had the impression that that's the sort of system that Jordan was speaking against. It's decidedly "first generation" (as one poster later in the darwin-dev thread distinguished).
Jordan was calling for more advanced internals (XML-based index, separation of data from control from execution engine, etc.), and not just smooth functionality, which has evolved to a good point in existing systems. Truth is, fink is very inflexible (e.g. little choice in install directory), offers very limited individual configuration options, and has its data entwined with its execution engine.
What Jordan suggests may even imply a step back in functionality at first, but I do believe it's the way forward, long-term.