On Aug 14, 2009, at 4:32 AM, Andreas Rottmann wrote:
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).
What I meant by packager is not the human, but the program that
constructs the package tgz file from the source tree. It's either
a simple dumb packager (e.g., tar czvf pkg.tgz <dir>), or a more
sophisticated one that does deeper transformation on the source
to make a package containing files and directories in the right
place.
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).
Yes, so, a transformation has to happen either when you make a
package or when you install a package.
A very simple scheme would be as follows:
* The meta file contains an optional file-mapping specification.
* When installing a package with no file-mapping specification,
everything in the package is copied to the destination by
default. So, a file foo.sls in some package would end up in
$DEST/foo.sls. (I still think that README, INSTALL, COPYING,
etc. files founds in the root of the package should be handled
in a special way, otherwise, any two packages containing a
README file would conflict; any suggestions?)
* When installing a package that has file-mapping specification,
the specified transformation is performed before the usual
mapping (above). The mapping spec can be just a list of rename
rules, srcfile/dir -> dest mappings, with the later (more
specific) rules overriding the former rules. So, if the source
tree contains a Readme.txt file (because that's how it's named
upstream), a rule for that would be ("Readme.txt" -> "README").
* A packaging tool *can* do the transformation on the source tree
when making a package, and if it does so, it would remove the
mapping rules since it already applied them. If one chooses
not to use a special packaging tool, then the installer tool
would do the transformation.
We probably should not tackle the issues of where to put various
things (e.g., documentation) as of yet and just rely on people
to put them in sensible places (a good convention might emerge
out of this).
Aziz,,,
