Abdulaziz Ghuloum <[email protected]> writes: > On Aug 12, 2009, at 7:56 PM, Andreas Rottmann wrote: > >> - Parallel-installability of the same collection with different >> versions, to ease transitions. A single program would just be able to >> use a single version of any library collection, but different >> programs could use another version of that same library >> collection. Effectively, you'd have different views upon the set of >> installed collections. > > This might be hard if the different conflicting versions are installed > in the same "root", but should be easy if you allow different library > roots for different programs. This would replicate some library files > but may be the easy way out. > Yeah, I've been thinking about just unpacking the individual archives into uniquely named folders, and then populate the installation roots with symlinks (on Windows, one would have to copy, I guess). Given packages like this (I'm using Debian syntax similiar to Debian control files here, but I guess we'd use s-exps):
Package: foo Tag: rotty # or branch, or user-id, or whatever Version: 0.0.1 Package: foo Tag: aziz Version: 0.0.2 Package: bar Tag: aziz Version: 0.1 Depends: foo (tag: aziz, version: (>= 0.0.2)) You end up with a directory structure like this: $REPO/foo-rotty:0.0.1/foo.sls $REPO/foo-aziz:0.0.2/foo.sls $REPO/bar-aziz:0.1/bar.sps $AZIZ_ROOT/foo.sls -> $REPO/foo-aziz:0.0.2/foo.sls $AZIZ_ROOT/scripts/bar.sps -> $REPO/bar-aziz:0.1/bar.sps $ROTTY_ROOT/foo.sls -> $REPO/foo-rotty:0.0.1/foo.sls The symlink approach would have the advantage of smaller disk space usage, and more importantly, IMHO, just having to compile each packages' libraries once. >> - Provide support for installation both per-user, and >> system-wide. Ensure that fabricating Debian or RPM packages from a >> library collection is easy and automatable as far as possible. > > Yes. > Question: can we use the debian tools (dpkg, apt-get, etc.) as is to > accomplish the task? What are the advantages/disadvantages? If not, > we can at least copy the state-of-the-art in dependency management, > conflict resolution, etc., instead of reinventing it. > You've answered that question yourself in another mail; for the record, here are the points that I think make re-using debian tools undesirable: - The packaging process is much more complicated than needed, given what we want to accomplish - We'd have to rely on tools written in C and tailored to GNU/Linux, or at least POSIX systems (Windows support would be a pain, I guess) - Debian packages are not meant for installation in e.g. $HOME >> I think there should be a single software package, using a liberal >> (e.g. BSD) license that implements that library collection management >> for R6RS implementations. Implementations could then include this >> piece of software, if they wish. >> >> I'd appreciate feedback on this issue, and I'd be willing to join >> hacking on a solution that targets R6RS implementations. > > I think we can start with a simple solution and get it running > quickly if we avoid overengineering. Here's one simple idea and > some additional criteria to get things started. Feel free to shoot > it down. > > 1. A package should be *easy to create* so that people feel encouraged > to make packages without hassle. > > 2. Package format should be *easy to process* so that (a) we don't > spend too much time developing it, and (b) others can easily hack it. > > 3. It should *meet current needs* but not more. > I agree with all these points. > > One possibility is to make a package a simple zip file to begin with. > The zip file contains files and directories of course. > Yeah, ZIP has the advantage of allowing random access to the contained files. I'm not sure however, if we need that feature, and couldn't just as well accept (compressed) tarballs (which would make sense with approach (1) below). > * We can consider top-level files "meta information", these may > include README, LICENSE, MANIFEST, COPYING, HACKING, or whatever. > These files get copied into a <root>/meta/<package-name> directory. > The MANIFEST file would probably contain the author name, license > info, dependencies on other packages, and small/long description. > I think we should reach consensus on a IMHO fundamental issue before starting to specify the layout of packages: Do we want (1) packages that are basically just the zipped contents of e.g. a VCS checkout, plus some added metadata; or do we want to (2) have some kind of description describing how to generate a package from a VCS checkout? (2) is what Debian (and RPM distros) do, while (1) is more like Gentoo or BSD ports. Since I'm pretty sure we don't want to ship "binary packages" with precompiled stuff in them, I think we should go with (1). One thing to keep in mind, though, is that both systems keep packaging metadata and the actual source code separate, for good reasons -- they are fundamentally orthogonal; for example, Debian may change its policy, requiring (the Debian part of) many packages to change, without needing to change the underlying upstream source. I don't know if, or to which degree, that will matter in our context, however. This can be interpreted as an argument for using approach (2), as that would decouple the actual packages from the upstream sources. > * We consider top-level directories "information", and these include > library files (structured as directories), and may include other info > that these libraries need (text files, images, etc.). Typically, > there would be one directory per package, but there might be more. > These get copied into the <root> directory. > If we go with the option (1) from above, I think this imposes unnecessary restrictions on how people organize their source code. A more flexible solution IMHO would be having a single metadata file with a fixed name in the root directory of the package. (I think we should be a bit flexible in where we look for that file; if for example the package contains just a single top-level directory, we should look there. This would allow a release tarball to directly serve as a package). That metadata file would describe the various parts (scheme libraries, documentation, etc.) and where they should end up below the installation root. This would be similiar to what scsh-install-lib's[0] pkg-def.scm files and my current ad-hoc sys-def.scm files contain. For an example of the latter, see [1]; here the `r6rs-libraries' form contains an alist having the package's file or directory path in its CAR, and the path relative to the implementation's library path in the CDR. If a package doesn't contain an `r6rs-libraries' form, I fall back to just placing the packages' top-level directory in the library path (similiar to what you suggest). [0] http://lamp.epfl.ch/~schinz/scsh_packages/ [1] http://github.com/rotty/prometheus/blob/3323c185c4d1daea03fd2108aac3291835c1a715/sys-def.scm > * The <root> directory can be either system-wide or user-specific. I > think we can start with having a single root and take it from there. > > The <root> directory can be added to IKARUS_LIBRARY_PATH, or whatever > and all libraries under the <root> would then just work. > > * The package manager itself can be a package installed in its own root. > To bootstrap the system, you just unzip the package manager somewhere > and add its directory to your PATH. > > * We let everything else work by convention and anarchy. > > To serve packages (over HTTP), a repository is just a directory > containing the packages' zip files and a special Packages files (like > debian). The Packages file contains the information that the tools > need: list of the package names, authors, dates, files and > directories, dependencies, etc. The package manager has a list of > repositories and you can do apt-get- style management. > > For people who host their libraries on bzr/git, we can probably make a > quick repositories that periodically pulls changes, builds zip files, > and updates the Packages files. So, we can have a semi-centralized > place where one can obtain all interesting packages. > > I don't think this would take more than a week of hacking, if we use > existing tools (e.g., curls for HTTP, zip for packing/unpacking, etc). > Yep, that's pretty much how I imagined it would work. Cheers, Rotty -- Andreas Rottmann -- <http://rotty.yi.org/>
