That was an excellent reply. I'll try to simplify my argument to your 3 points in the future.
I've looked at Klick and the author's new project, and various other projects. I think Zero Install has the most complete vision, and some code, users and experience. The current state of Zero Install unfortunately has various limitations. For example, it only addresses ease of installation, not how to find packages. It does not address the need for developers to share libraries with each other. It's only for installing applications you can run directly. While it works on Windows and Mac to some extent, it's a lot like git in that much of it is script based and assumes you're running on a GNU/Linux system. I would prefer better cross-platform support and an architecture more like mercurial (as opposed to git) which uses cross platform tools and avoids GNU/Linux scripts. They leave the job of building a cross-linux installable package to the user, though they have a helpful wiki. Basically you have to compile all your depended libraries from source on some old linux distro and link statically. It's not exactly an ideal solution. However, I think they have many of the right ideas. > One major pitfall of many of these approaches is that an end-user without > administrative privileges is often excluded even from installing applications > made available in this way. I have investigated various approaches involving > actual Debian packages and fakechroot in order to empower non-root users, and > I think that such considerations would have to be part of any eventual > solution. I agree. There's no technical reason I can see why such a system couldn't run on servers like we have at my work running Debian Lenny, which would allow people to run a lot of apps without bugging our IT guy. > To an extent a chroot solution will only get you so far, in my experience, as > there can be other factors that make libraries incompatible. And I guess that > initiatives such as LSB only go so far to preserve binary library > compatibility, anyway. It also seems to me that build tools have become more > in conflict with packaging tools over time, but I'm sure there are many > people with Debian packaging experience who can relate more detailed > experiences about such matters than I can. Now in reality, I doubt any of my specific ideas are going to be the bases of any sort of solution, so I don't want to debate my theoretical solution too much. However, I was thinking that when packaged, the version and hash code of every library and file used by the application would be recorded. The application would specify what depended libraries it was picky about keeping the same, and which could be upgraded, probably with the default no-work option being that everything had to be exactly the same. So, by default, you'd get the maximum disk bloat, but minimum library compatibility problems. If you're smart, you probably specify that you have some flexibility in your Qt library, X windows, Python interpreter, Java JVM, etc, so you don't bloat the disk with hundreds of megabytes of obsolete libraries. If users run into problems, they would have the ability to switch any or all of an applications depended libraries to the version used originally. This sort of thing could also be useful if the user wanted to use a non-standard version of a major library like GTK+. It would be awesome to be able to select which branch or fork your system uses by default. You should also be able to use the version provided by the distro through the existing native package system. > On the subject of finding applications: > >> We need a cross-distro App Center, where software can be published >> with zero or minimal review, and then run on any GNU/Linux platform. >> There has been efforts in this direction recently. The Zero Install >> guys are making good progress, for example. There was a meeting >> recently where various distros discussed a cross-platform package >> installer, but it ended in everyone agreeing to continue with business >> as usual with a band-aid on top that wont make any difference. > > I think Zero Install is an interesting solution, but I also think that it > would be beneficial to leverage existing packages. Here, we need to separate > the orthogonal concerns of packaging, distribution and installation. As I > noted above, if it merely becomes possible for an unprivileged user to > install proper Debian packages in a sandbox, then significant benefits are > already gained: in many cases, the alternative to such users is a build from > source of a hierarchy of dependencies or to use an inferior solution like > easy_install (the Python package installer), which means that they are > already missing out on existing distribution facilities without even > considering the universe of unpackaged software. All good points. Thanks for the discussion. I am in fact interested in building or helping to build a new cross-platform packager and package installer. The first application I would like to support is a new cross platform text-to-speech engine I'm helping develop. The output of the packager could be .deb and .rpm files, to take advantage of the systems already there in the different distros, but the binaries would be portable between Linux distros as much as possible. I might be able to work with the Zero Install community, but it remains to be seen. Frankly the greatest risk factor in such a project is me. It's a huge project. I'd rather join a project and help it succeed. Bill -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOLP8p5AAHCBYVp=khaP-H2EDkZi3feo=lgw53eepa9judg...@mail.gmail.com