Consider this context: under Windows, start can generally be trusted to attempt some useful "launch the application/document/item/...", very much as command-line open does under Mac OS X.

At a policy level, one also often hears, "Well, there are good standards for installing an application under Windows (or Mac OS X), but Unix (or Linux) is 'all over the map'. Unix needs a framework so we don't have to develop a separate installer... for each flavor."

The Portland project [1] aims to fulfill that need.

[Provide magazine references.]

"Portland provides desktop portability" [2]

---

LV Sigh - yet another project where someone decides they don't like any of the existing solutions, so they go off to create their own silver bullet. It may be wonderful. Who knows? What I do know is that it is a non-trivial task to set out to create a framework that would be used on all unix and unix-like systems. Sun did it with NFS . And perhaps, someday, someone will do it with installation. But the way to do it is to clearly identify what is broken (not just what doesn't work the way you want it too, or what is done in dozens of different and incompatible manners.). And if Portland has done this, it should be one of the first things one sees when they visit that web site. I don't see that today.

hat0 just curious--what existing solutions?

---

At least, it does, very broadly. While several bright people [provide references] are enthusiastic about Portland, CL regards its ambitions as severely limited. Even when the first couple of releases of Portland are complete, it will leave many, MANY questions of interoperability unanswered. 2007 might end with Portland only creeping past its x86-Linux GNOME-KDE base.

On another hand, Portland has good people working on it, it seems to be meeting its modest deadlines, and it does help with several specific technical issues. For example, xdg-open [3] is close to the start mentioned previously.

[Mention that, while the command-line interfaces are likely to continue to be of most interest to the Tcl crowd, C bindings will eventually appear.]

---

DKF: I admit I'm definitely sceptical of Linux installers. The problem is that if they're driven by the vendors (the main folks to actually get any traction in the mainstream Linux space) then it'll effectively end up with assuming that it's only ever run by root; the vendors (as a group) do not understand the real requirements of people for installation by non-root users or for ensuring that apps are isolated from each other. If the vendors aren't in the game, then 10-to-1 it never happens in any meaningful way.

I prefer the tclkit approach of copy-to-install, delete-to-uninstall. :-)

LV Yes, I agree Donal. For instance, Unix installers which require one to be root so they can create partitions - having the ability to point to an existing partition so as to skip the root requirement would be wonderful. Installers wanting to install things into /etc , rather than providing files that could be given to someone running as root to install, would be a better solution. Most attentive system admins try to avoid running installation programs as root as much as possible - and if the installation program isn't a standard shell script, they really want to avoid it, because it makes checking things tougher. No matter how smart an install script writer is, it cannot possible anticipate all the various circumstances that someone wanting to use the software might encounter.

escargo 13 Mar 2007 - The Zero Install[4] system is intended to solve some of those issues.

DC What a load of crap. I think you have to take responsibility for what you install on your system no matter how it's packaged. Most applications don't need root. The current cadre of packaging systems all require root just to register the package, but you don't see people complaining about RPM and dpkg.

And, by the way, Portland is just a set of shell scripts that create desktop shortcuts and install icons and stuff. It is not meant to be an installer of any kind. It's meant to be used BY installers like RPM and dpkg as a way for developers to create shortcuts as they install their applications. It doesn't do any more than that.

---