Re: CVS is the `released version'

[Tom Tromey]

>>>>> "rms" == Richard Stallman <address@hidden> writes:

rms> Maybe it is worth doing that, though calling it a "package
rms> system" seems like hype.

Perhaps we have different ideas about what this means.  My use comes
from the distro world, where it basically refers to the combination of
"binary" downloads and dependency tracking.  I'm not a real lisp
programmer but I gather this has some other meaning in the lisp
world...?

rms> 1. It could reduce the incentive for people to assign copyright
rms> on their code.

Yeah, this is definitely to be preferred.  I'm not comfortable
requiring it, though, because there are very useful Emacs Lisp
packages which, AIUI, will never be assigned to the FSF.

rms> 2. It would mean that Emacs refers people very strongly to a site that
rms> isn't run by the GNU Project.  I don't know what their policies are.
rms> But even if they are good, now, we have no way to assure that remains
rms> so.

Currently there is no "they", just me :).  My current policy is that
ELPA accepts anything that is free software.

Of course we could have an official GNU ELPA and then also change
package.el to support multiple repository URLs, so that users could
point to some non-FSF repository.

I wouldn't have a problem asking people to assign their code first,
and only uploading to the other repository if they say no.

>       It also mandates a
>     couple file names, the main one being the .el file that holds the
>     "define-package" call.

rms> Something like a "define-package" call is one of the things that makes
rms> me dislike package systems.  Can we avoid this?  Why is it needed?

It is only needed for multi-file packages.  Essentially package.el
needs 3 pieces of information about a package: its name, its version
number, and its requirements.  For a single-file package these are
extracted from comments; package.el defines a new comment header
("Package-Requires") for requirements, but so far I think this is
unused.

For a multi-file package the problem is just knowing where to look to
get this information.  It seemed simplest to have the package
maintainer provide it in a well-known place.

For a single-file package the quux-pkg.el file is generated by
package.el at install time.

Tom