help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Packages, release notes, etc


From: Tassilo Horn
Subject: Re: Packages, release notes, etc
Date: Thu, 10 Sep 2015 11:22:18 +0200
User-agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.0.50 (gnu/linux)

Michael Welle <mwe012008@gmx.net> writes:

Hi Michael,

> I have noticed that a lot of packages (at the least of the packages I
> have installed) come without release notes, the explicit copyright
> notice and all the other 'meta data'. Is there some kind of consensus
> on how that should be handled or is it just the way it is?

The documentation in (info "(elisp)Library Headers") suggests that each
elisp file should have the following header:

,----
|      ;;; foo.el --- Support for the Foo programming language
| 
|      ;; Copyright (C) 2010-2015 Your Name
| 
|      ;; Author: Your Name <yourname@example.com>
|      ;; Maintainer: Someone Else <someone@example.com>
|      ;; Created: 14 Jul 2010
|      ;; Keywords: languages
|      ;; Homepage: http://example.com/foo
| 
|      ;; This file is not part of GNU Emacs.
| 
|      ;; This file is free software…
|      …
|      ;; along with this file.  If not, see <http://www.gnu.org/licenses/>.
`----

So in general, metadata such as copyright notice, author, maintainer,
and homepage should always be available no matter how a package is
distributed, e.g., just from SCM, via tarballs, or via the emacs package
manager.

With respect to license, I think it is not even possible for an emacs
package to have a license different than GPL version 3 or later.  Each
package is a combined work of emacs + X so the emacs license extends to
the package.  That's probably the reason why there's no special License
field in the standard headers.

Things like a ChangeLog or release notes are optional and up to the
package maintainer.  Some packages have them either in separate files,
in their info documentation, or included as comment in the package's
main file.

I think that the above conventions are strictly enforced at least for
all packages from the official GNU ELPA package archive but there might
be packages from MELPA or Marmalade which are lacking this metadata.
I'd report a lack of the standard headers as a bug to the bugtracker of
the respective package.

Bye,
Tassilo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]