On Aug 13, 2009, at 6:34 PM, Andreas Rottmann wrote:
Abdulaziz Ghuloum <[email protected]> writes:
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).
I don't like excessive symlinking like you describe. For version 1,
we should keep it simple and disallow installing two packages that
provide the same file. (after all, we don't have 1000s of packages
to worry about, yet)
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))
So, the UID of a package is the triplet {name,tag,version}, right?
So, you can have packages with the same name and tag, but different
versions, or same name and version, but different tags, etc, right?
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.
Maybe there are advantages, but they won't be obvious immediately.
Single root is simpler to boot, I think.
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
We all seem to be in agreement here. Apt is out.
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).
The package manager would probably want the MANIFEST file, or some
other meta file, without having to uncompress the whole archive.
I honestly don't know all the pros and cons of zip vs tar.gz files.
Do you know when one would choose one over the other?
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).
I think I agree.
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.
I don't think it matters much in our situation since the meta info can
be kept in a single file that the package developer is going to supply
and maintain alongside the sources anyways. Right?
* 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.
A single meta file is fine by me.
(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).
Do you mean go all the way down until you find it, or just one directory
down?
That metadata file would describe the various parts (scheme libraries,
documentation, etc.) and where they should end up below the
installation
root.
One part of me says that users should not specify where things get
installed, and not list package contents, and that the installer
should be smart enough to do the right thing. Basically, the packager
should be dumb (zip and ship) while the installer is smart.
Another part of me says that the opposite is the way to go: The
packager should take care of assembling the package in exactly the
right shape, and the installer could be dump (unzip and go).
This might be another way of characterizing the differences between
the two options (1) and (2) above.
I probably need to sleep over it for a couple of nights and see what
I (and others, please!) can think of.
Aziz,,,
