Thank you. Your feedback has been most informative. I'll try to deal with each of the issues I (think I) understand, to the best of my knowledge.
> we don't have a package database - or rather the filesystem is the database. Ah, yes. Sorry, that is what I meant by package database. I was unaware it was as simple as cp etc to add the software to your "database". That's awesome. > I don't know if this is what you stated above, but we do have a > binary package format, binaries in an archive. > We also support third-party, non-free binaries, like flash and video > drivers by just unpacking them into our file system and symlinking > them. Is this what you're after? Your existing binaries could probably be used with Zero Install to perform automatic dependency handling and non-root installation. Zero Install would may need to have an additional optional component for symlinking. I'll ask the Zero Install developer if he would mind implementing this. > what needs to be flexible about it? Good point. I didn't clarify that at all. The hope is for it to be flexible enough that it can be installed across a variety of distributions. If other distributions decide to use Zero Install as well, that means there is likely to be even more packages available for your distribution. > For example, Nix binaries are > stored in "Nix Archive" format which is a deterministic representation > of the (relevant properties of a) filesystem tree -- because that's > useful for their purposes. Curiously, it turns out that they can > generally be relocated in a limited way by hash rewriting, e.g. between > /nix/store/r8vvq9kq18pz08v249h8my6r9vs7s0n3-firefox-2.0.0.1/ > and > /nix/store/5lbfaxb722zpef8dhd9np843hc23ja2n-firefox-2.0.0.1/ > . > ( http://nixos.org/about.html ) Actually, Nix and Zero Install are fairly similar, though Nix tries to use the same form of dependency handling for the whole system rather than user-level programs - as I understand it. > [binaries] tend to depend on the > exact dependencies they were built against, unless you get lucky. Zero Install handles the supported versions of dependencies automatically as well. ;) It's even configurable. Also, I have read that building software against older versions of dependencies is _likely_ to make it work on the newer ones. See older GTK+ headers. http://autopackage.org/download-tools.html > Problem with supporting installs from deb, rpm or any other package > format is that we have to implement and support dependency tracking I have good news! If you were to integrate Zero Install, you would have support for debs, RPM, autopackage and standard binaries without having to implement anything! It also has automatic dependency handling! > "download the binaries from third-party website" sounds like a bad idea > to me. When I'm on Linux-PPC for example, it's highly unlikely that any > third-party website (even if I trusted its binaries) would have any. I appreciate your concerns, however Zero Install does handle architectures. If the third party has one for your architecture, it'll be downloaded. If not, it will download and compile the source code. This may happen via Compile in the near future, though this is still simply a consideration for now. > does zero-install attempt to take distros out of the picture? That > might be interesting. Yes, assuming you mean attempting to make cross-distribution installation possible. Would it be possible to use Compile with some Autopackage tools that are designed at making binaries portable. This, thankfully, does not mean that you _have_ to use Autopackage with the binaries. What do you think? http://autopackage.org/download-tools.html Thanks, Matt _______________________________________________ gobolinux-devel mailing list gobolinux-devel@lists.gobolinux.org http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
