Abdulaziz Ghuloum <[email protected]> writes:
> 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 that the symlinking approach only gives advantages when having
multiple roots, and "stage 1" would target single roots only, I'm fine
with that.
>> 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
>>
[...]
>
> 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?
>
Yes, that was what I had in mind.
>> You end up with a directory structure like this:
>>
[...]
>> 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.
>
Fine with me.
>>> 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.
>
Hmm, I think we can get away without having to look into the package, as
the relevant metadata would be available "per archive" in an aggregated
file (like Debian's Packages.gz).
> 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'm no expert on this topic, but I think two of the relevant differences
are:
- Zip has better tool support on Windows, while compressed tarballs are
more common on UNIX/POSIX platforms. IMHO, we shouldn't care about
Windows in that regard, since while there may be something like WinZip
on many (or even most) Windows machines, we can't rely on that, and
need something with a standardized command-line interface
anyway. OTOH, on GNU/Linux you can pretty much rely on tar and gzip
being present, and bzip2 is commonly installed as well (if not it's
just an "$PKG_MANAGER install" away :-).
- The already mentioned random access issue. If we really need that, it
would surely make the case for Zip.
>> 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?
>
I think you are right; I've just asked about this on #debian-devel, and
was referred to [0]. I think we're actually much more in an RPM
situation than in a Debian situation, FWICT. I guess nowadays, where you
(as a Scheme code packager) can rely on a VCS that allows easy branching
and merging, and probably can deal with (or import) your upstream's (if
there's one) source, there is no reason to mandate separating the
packaging meta-info from the source.
[0]
http://kitenet.net/~joey/blog/entry/on_debian_directories_in_upstream_tarballs/
>> (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?
>
I meant going just one directory down. Would there be any sense in
looking further?
>> 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).
>
Well, the packager is human and the installer is a program. I think we
can, at least ATM, assume in the general case the former is smarter than
the latter ;-). Seriously though: encoding less meta-information in the
package means we are more flexible on what the installer can and can't
do. OTOH, not requiring meta-info to be present means more insecurity
about changes in the installer not breaking packages (which might well
be constructed prior to the change in installer behaviour).
> This might be another way of characterizing the differences between
> the two options (1) and (2) above.
>
Yeah, one could consider the meta-information, even in option (1), as a
transformation of the (source) package to the installed form (binary
package).
> I probably need to sleep over it for a couple of nights and see what
> I (and others, please!) can think of.
>
I'd also very much welcome additional perspectives, especially from
people who have some experience with packaging systems from CL, Perl,
Python, Haskell, etc.
[ I wonder if we should carry that discussion over to comp.lang.scheme,
although posting to Usenet these days is quite a hassle for me, due to
having no way to post via NNTP -- Google groups sucks big time
compared to a decent news client. Anybody operating or knowing about a
private NNTP server or mail2news gateway perhaps? ]
Cheers, Rotty
--
Andreas Rottmann -- <http://rotty.yi.org/>
