mirror of git://git.sv.gnu.org/emacs/elpa
631 lines
24 KiB
Plaintext
631 lines
24 KiB
Plaintext
#+TITLE: GNU ELPA README
|
||
#+DATE: 2022-10-26
|
||
|
||
Copyright (C) 2010-2022 Free Software Foundation, Inc. \\
|
||
See the end of the file for license conditions.
|
||
|
||
#+BEGIN_COMMENT
|
||
This file exists in two branches ~elpa-admin~ and ~elpa~. The two version
|
||
differ slightly. The introductory text before the first heading
|
||
differs and there are minor differences concerning the ~externals/*~ to
|
||
~elpa/*~ transition. Please make sure you always update this file in
|
||
both locations to avoid introducing additional differences. This
|
||
duplication will be removed eventually.
|
||
#+END_COMMENT
|
||
|
||
This repository contains the sources, deployment scripts, and
|
||
auxiliary files for [[https://elpa.gnu.org/][GNU ELPA]]. GNU ELPA is a [[https://www.gnu.org/philosophy/free-sw.html][free software]] Emacs Lisp
|
||
Package Archive (ELPA) with extensions to [[https://www.gnu.org/software/emacs/][GNU Emacs]].
|
||
|
||
This file explains the repository layout, how to add and edit
|
||
packages, and how to deploy the archive (either on =elpa.gnu.org=,
|
||
or a local copy for testing purposes).
|
||
|
||
* Repository layout of elpa.git
|
||
|
||
The layout of the =elpa.git= repository is as follows:
|
||
|
||
- The =main= branch holds the list of specifications of the packages
|
||
included. It does not hold the scripts to build them.
|
||
|
||
- The copy of the code for a package =<pkg-name>= is not kept in
|
||
=main= but in a branch named =externals/<pkg-name>=.
|
||
Package branches are normally placed as git worktrees in the
|
||
subdirectory =packages/<pkg-name>= (see below).
|
||
|
||
- The package archive deployment scripts are in the =elpa-admin=
|
||
branch. This branch is normally put as a git worktree in the
|
||
=admin= subdirectory.
|
||
|
||
* Getting the source
|
||
|
||
Start with source that is cloned directly from Savannah
|
||
(See [[https://savannah.gnu.org/git/?group=emacs][the Savannah page]] and look for "ELPA").
|
||
Using a clone of a clone might not work.
|
||
|
||
The repository is large because it contains all the packages, so you
|
||
will usually want to clone with =--single-branch= to avoid downloading
|
||
a large amount of irrelevant data. More specifically, here is how you
|
||
can get the source and setup the general infrastructure:
|
||
|
||
#+begin_src shell
|
||
git clone --single-branch git://git.savannah.gnu.org/emacs/elpa.git
|
||
cd elpa
|
||
make
|
||
#+end_src
|
||
|
||
Where the =Makefile= in the =main= branch is used to automatically
|
||
pull the =elpa-admin= branch to populate the =admin= subdirectory.
|
||
|
||
However, it leaves the =packages= directory empty; you must check out
|
||
the ones you want.
|
||
|
||
** Check out all packages
|
||
|
||
If you wish to check out all the packages into the =packages=
|
||
directory, you can run the command:
|
||
|
||
#+begin_src shell
|
||
make worktrees
|
||
#+end_src
|
||
|
||
** Check out specific package
|
||
|
||
You can check out a specific package =<pkgname>= into the =packages=
|
||
directory with this command:
|
||
|
||
#+begin_src
|
||
make packages/<pkgname>
|
||
#+end_src
|
||
|
||
The first time you run this command, it just populates that directory.
|
||
After that, it will (re)"build" the package for use in-place, i.e. it will
|
||
create (or refresh) the =<pkgname>-pkg.el= and =<pkgname>-autoloads.el= files
|
||
and (re)compile the ELisp files under the assumption that you have put
|
||
=.../elpa/packages/= into your =package-directory-list=.
|
||
|
||
** Updating a package directory
|
||
|
||
If you already have a =packages/<pkgname>= directory with a previous
|
||
checkout, you can update it like this:
|
||
|
||
#+begin_src
|
||
cd packages/PACKAGE
|
||
git pull
|
||
#+end_src
|
||
|
||
* Directory layout
|
||
|
||
This code expects to be used in a directory that has the following layout:
|
||
|
||
- =admin/= -- Directory containing a copy of the here files
|
||
- =GNUmakefile= -- A copy of or symlink to =admin/GNUmakefile=
|
||
- =elpa-packages= -- The specifications of the packages
|
||
- =elpa-config= -- Some configuration settings for the build scripts
|
||
- =copyright_exceptions= -- List of exceptions for the copyright-notices checks
|
||
|
||
The =copyright_exceptions= file can be absent, in which case copyright notices
|
||
will simply not be checked.
|
||
|
||
Additionally to the above, this code will then add to that directory
|
||
the following elements:
|
||
|
||
- =packages/= -- Directory holding Git worktrees of packages
|
||
- =archive/= -- Directory holding the generated files for the archive
|
||
- =archive-devel/= -- Same for the "bleeding edge" version of the archive
|
||
|
||
* Specifications (elpa-packages)
|
||
|
||
The specifications of packages is a `lisp-data-mode` file containing
|
||
a single Lisp list where each element describe a particular ELisp package
|
||
that should be part of the archive. Each element has the form
|
||
|
||
(NAME . PLIST)
|
||
|
||
where NAME is the name of the ELisp package and PLIST is a property list
|
||
giving additional info about that package. It has to have either
|
||
a =:url= or a =:core= property, all others are optional.
|
||
The properties are the following:
|
||
|
||
** =:url URL=
|
||
This property has to come first.
|
||
Gives the URL where the upstream Git repository for that package can be found.
|
||
The URL can be =nil= if there is no upstream repository.
|
||
|
||
** =:core FILES=
|
||
This property has to come first.
|
||
Indicates that this is a special package which will be built by extracting
|
||
files directly from Emacs's source code. For this to work, the Emacs
|
||
source code should be available in the =emacs= subdirectory.
|
||
FILES specifies the files that will be contained in the generated tarballs.
|
||
It can be a single file name or a list of file names.
|
||
|
||
** =:branch BRANCH=
|
||
Specifies the branch to follow in the upstream Git repository, in case
|
||
it should be different from the default branch.
|
||
|
||
If there is no upstream (=:url= is nil), this is simply ignored.
|
||
|
||
** =:lisp-dir=
|
||
Subdirectory in which the main ELisp found are found.
|
||
Defaults to the top-level directory.
|
||
|
||
** =:main-file FILE=
|
||
Gives the name of the main file of the package, i.e. the file in which
|
||
the metadata can be found in the form of pseudo-headers like "Version:".
|
||
It needs to be an ELisp file formatted following the proper conventions.
|
||
This is normally the file [PKG].el in the LISP-DIR, but in some rare
|
||
circumstances the file is named differently.
|
||
|
||
** =:release-branch BRANCH=
|
||
The upstream BRANCH from which releases are cut. This is only used
|
||
for those packages which have both a development branch and a release branch
|
||
and only if the version number in the development branch indicates that it
|
||
contains development code (i.e. a "snapshot" version, according to
|
||
`version-to-list`).
|
||
|
||
If there is no upstream (=:url= is nil), the presence of :release-branch
|
||
just indicates that release and devel branches in elpa.git are desired
|
||
(the name given in :release-branch is ignored). The release branch is
|
||
named `externals-release/<pkg-name>' for GNU ELPA and
|
||
`elpa-release/<pkg-name>` for NonGNU ELPA. The standard package branch
|
||
externals/<pkg-name> is the devel branch in GNU ELPA; the standard
|
||
branch elpa/<pkg-name> is the devel branch in non-GNU ELPA.
|
||
|
||
** =:ignored-files FILES=
|
||
Names of files or directories that should not be included in the tarballs.
|
||
|
||
** =:renames RENAMES=
|
||
Mapping from the source layout to the layout used in the tarball.
|
||
RENAMES is a list of element (FROM TO) where FROM should terminate with =/=
|
||
if it's a directory.
|
||
If =:lisp-dir= is set, then that directory is renamed to =""= without
|
||
having to specify it here.
|
||
|
||
** =:readme FILE=
|
||
Name of the file to use as the description of the package. By default
|
||
we try to use README, README.rst, README.org, or the Commentary section
|
||
in the main file. If ~ignore~, ignore any matching file and use the Commentary
|
||
section.
|
||
|
||
** =:news FILE=
|
||
Name of the file that contains the list of changes in recent versions
|
||
(listed from more recent to least recent).
|
||
By default we try to use NEWS, NEWS.rst, NEWS.md, NEWS.org, the News section
|
||
in the main file.
|
||
|
||
** =:doc FILE=
|
||
Name of the documentation file for the package.
|
||
It can be either an Info file, a Texinfo file, or an Org file.
|
||
FILE can also be a list of those.
|
||
|
||
** =:make TARGET=
|
||
Indicates that we should run ~make TARGET~ in order to build some files.
|
||
This is run before processing =:doc=, so it can be used to generate
|
||
the Info and Texinfo file from some other format.
|
||
TARGET can also be a list, in which case each target should be
|
||
an actual file name (rather than a "phony target").
|
||
|
||
** =:shell-command COMMAND=
|
||
If running =make= is not good enough, this lets you run the shell COMMAND
|
||
to build (or modify, rename, delete, younameit) some of the files.
|
||
|
||
** =:version-map MAP=
|
||
A list of elements of the form (ORIG-VERSION REMAPPED-VERSION REVISION).
|
||
This allows replacing the ORIG-VERSION from the [PKG].el file
|
||
with REMAPPED-VERSION (e.g. because the ORIG-VERSION is not a valid
|
||
version number, is missing, or because we want to create a new package
|
||
from the same code version).
|
||
It also makes it possible to specify which REVISION corresponds to
|
||
this ORIG-VERSION (or REMAPPED-VERSION if non-nil) to override
|
||
the default heuristic which uses the last revision that modified the
|
||
"Version:" header.
|
||
|
||
** =:merge BOOL=
|
||
If non-nil, this setting indicates that syncs from upstream should use automatic
|
||
merges instead of fast-forwards.
|
||
This only works for the main branch, not for the release branch.
|
||
An unnecessary =:merge= setting is considered as an error.
|
||
|
||
This option has many shortcomings, so its use is discouraged: it is
|
||
better avoided as much as possible. Among other problems, merges
|
||
don't interact well with the algorithm used to determine which
|
||
revision is a "release".
|
||
|
||
* Configuration (elpa-config)
|
||
|
||
The configuration file is a `lisp-data-mode` file containing
|
||
a single Lisp list setting various options. Each entry in the list is of
|
||
the form
|
||
|
||
(NAME VALUE)
|
||
|
||
where NAME is one of:
|
||
** =name= The name of the ELPA archive, used in the HTML pages.
|
||
** =url= The public URL of the ELPA archive.
|
||
** =gitrepo= The base URL of the Git repository holding the packages.
|
||
** =branch-prefix= A prefix added to the packages's branches in the gitrepo.
|
||
** =release-branch-prefix= Same but for the release branches.
|
||
** =specs-file= Name of the specification file (default: =elpa-packages=).
|
||
** =email-to= Email address to which to send announcement of new releases.
|
||
** =email-from= Email address to use in the `From:` field.
|
||
** =email-reply-to= Email address to use in the `Reply-To:` field.
|
||
** =sandbox= If non-nil, use a `bwrap` sandbox to run commands (default: =t=).
|
||
** =sandbox-extra-ro-dirs= Additional directories to make readable to `bwrap`.
|
||
** =debug= If non-nil, emit more detailed messages.
|
||
** =copyright-file= Name of a file containing copyright check exceptions.
|
||
|
||
* Make targets
|
||
|
||
** =all-in-place=
|
||
This is the default target, and it prepares all the directories found in
|
||
the =packages= subdirectory for use by =package.el=. This assume you will
|
||
want to add =.../packages= to your =package-directory-list= so as to treat
|
||
those packages as installed "in place".
|
||
|
||
** =packages/[PKGNAME]=
|
||
Prepare the subdirectory =packages/[PKGNAME]= for use by =package.el=.
|
||
If the directory does not exist yet, it checks it out as a Git worktree.
|
||
Else, it generates the auxiliary files like =[PKGNAME]-pkg.el= and
|
||
=[PKGNAME]-autoloads.el= and compiles the Elisp source files.
|
||
|
||
** =[PKGNAME].tar=
|
||
Build that tarball from the commit currently in =packages/[PKGNAME]=
|
||
|
||
** =build/[PKGNAME]=
|
||
Build the ELPA tarball(s) and other files like PKGNAME.html and
|
||
PKGNAME.svg for PKGNAME. The result is placed in the =archive= and
|
||
=archive-devel= subdirectories.
|
||
|
||
This can be used to test commentary and changelog extraction.
|
||
|
||
** =build-all=
|
||
Same as before but does it for all the packages listed in the
|
||
=elpa-packages= file.
|
||
|
||
** =fetch/[PKGNAME]=
|
||
Fetch changes from the upstream repository of package PKGNAME.
|
||
Does not apply them to anywhere, only keeps them in Git and shows
|
||
a concise summary of the new commits compared to the current
|
||
content of the archive.
|
||
|
||
** =fetch-all=
|
||
Same as before but fetches changes for all the packages listed in the
|
||
=elpa-packages= file.
|
||
|
||
** =sync/[PKGNAME]=
|
||
Fetch changes from the upstream repository of package PKGNAME
|
||
and push them to the corresponding branch in the main repository (such as
|
||
=elpa.git=).
|
||
|
||
** =sync-all=
|
||
Same as before but does it for all the packages listed in the
|
||
=elpa-packages= file.
|
||
|
||
** =clean=
|
||
Delete all the files generated by a plain =make=.
|
||
|
||
** =clean/[PKGNAME]=
|
||
Delete all the files generated by =make packages/[PKGNAME]=.
|
||
|
||
* Text below this marker is OUTDATED and still needs to be reviewed/rewritten!!
|
||
|
||
* Packages
|
||
|
||
** Contents of the =packages/= directory:
|
||
This directory holds the package sources, with one subdirectory for
|
||
each package.
|
||
|
||
Each directory in here corresponds to a package.
|
||
|
||
A nightly cron job on the server hosting =elpa.gnu.org= refreshes the
|
||
GNU ELPA archive from this repository.
|
||
|
||
This cron job only creates a new package when the "version" (as specified in
|
||
the =Version:= header) of a package is modified. This means that you can
|
||
safely work on the next version here without worrying about the unstable
|
||
code making it to GNU ELPA, and simply update the =Version:= when you want to
|
||
release the new code.
|
||
|
||
** To add a package: (submission, submit)
|
||
|
||
Adding a basic package is very simple. There are thorough
|
||
instructions below, but the gist of it is that you:
|
||
|
||
1. Notify [[mailto:emacs-devel@gnu.org][emacs-devel@gnu.org]].
|
||
2. Push your package's code to its branch on elpa.git with:
|
||
|
||
#+begin_src shell
|
||
git push elpa <mybranch>:refs/heads/externals/<pkgname>
|
||
#+end_src
|
||
|
||
where =<mybranch>= will probably be =master= for most people.
|
||
[ Note: The name "externals/" is the result of an accident of history. ]
|
||
|
||
3. Edit the =elpa-packages= file to add an entry for =<pkgname>=.
|
||
It has to have an =:url= property specified but that
|
||
property can be nil.
|
||
4. =git add elpa-packages=, =git commit= and =git push=.
|
||
|
||
If you don't have push access to the repository, someone will do steps
|
||
2-4 for you.
|
||
|
||
*** Notify emacs-devel@gnu.org
|
||
|
||
There is no approval process for GNU ELPA packages. Still,
|
||
you must send an email to =emacs-devel= for several reasons:
|
||
|
||
- Notifying other developers;
|
||
- Making sure the package doesn't break FSF rules;
|
||
- Checking if the package is not reinventing the wheel;
|
||
- Ensuring that first-time developers are doing it right.
|
||
|
||
Before doing anything, please ensure your package follows the
|
||
conventions described in the [[Format]] section. Then, send an email
|
||
to the list with the subject:
|
||
: [ELPA] New package: <pkg-name>
|
||
|
||
Start your message with an explanation about the package. A
|
||
copy-paste of the package's =Summary= and =Commentary= is perfectly fine
|
||
here, but you can write more or less than that if you'd like.
|
||
|
||
In your message include the URL of a Git repository where your package can
|
||
be found (or if that's not convenient and the package is small enough,
|
||
include a copy of its code as an attachment). If you prefer (and if you
|
||
have push access), you can push your changes to a branch called
|
||
=scratch/<pkg-name>=, and mention the branch in your message.
|
||
|
||
After 48 hours, or once any issues have been addressed, someone will push
|
||
your changes for you. You should probably also subscribe to
|
||
[[https://lists.gnu.org/mailman/listinfo/emacs-devel][emacs-devel@gnu.org]], since that's where we discuss about GNU ELPA, and
|
||
to [[https://lists.gnu.org/mailman/listinfo/bug-gnu-emacs][bug-gnu-emacs@gnu.org]], since that's where people will report bugs
|
||
about your package.
|
||
|
||
*** Add a simple package as =<pkg-name>.el=.
|
||
|
||
The file needs to follow the usual coding conventions (most importantly start
|
||
with =";;; <file> --- <description> -*- lexical-binding: t -*-"=) and have a
|
||
=Version:= and =Maintainer:= pseudo-header (see the [[Format]] subsection
|
||
below).
|
||
|
||
For some examples, see [[https://www.gnu.org/software/emacs/manual/html_node/elisp/Simple-Packages.html][Simple Packages]] (web link) or in Emacs:
|
||
#+begin_src elisp
|
||
(info "(elisp) Simple Packages")
|
||
#+end_src
|
||
|
||
*** Add a multi-file package as a directory
|
||
|
||
It needs to have a file named =<pkg-name>/<pkg-name>.el= which follows the
|
||
same rules as above.
|
||
|
||
It additionally follows the same guidelines described in [[https://www.gnu.org/software/emacs/manual/html_node/elisp/Multi_002dfile-Packages.html][Multi-File Packages]]
|
||
(web link) or in Emacs
|
||
#+begin_src elisp
|
||
(info "(elisp) Multi-file Packages")
|
||
#+end_src
|
||
with the exception that it is not a tar package (it's a plain
|
||
directory) and it must not contain a =<pkg-name>-pkg.el= file (this
|
||
will be created for you).
|
||
|
||
*** Check the copyright
|
||
|
||
Now run =make check_copyrights=.
|
||
|
||
That command does a very crude check to try and catch the files which lack
|
||
the usual license and copyright blurb (that's the role of the first =find=),
|
||
and to catch the files which still have a "copyright <not-the-fsf>" somewhere.
|
||
|
||
If your package fails that check, please fix the files accordingly.
|
||
Of course, occasionally those checks misfire (for a few rare files which
|
||
we admitted without their copyright being transferred to the FSF, or
|
||
because the word "copyright" appears in the body of the file), in
|
||
which case the right fix is to update the =copyright_exceptions= file.
|
||
|
||
*** Commit your changes the usual way (=git add=, =git commit=, etc.)
|
||
|
||
Changes in the Git repository do not immediately propagate to the
|
||
user-facing archive (what users see when they do =M-x list-packages=).
|
||
That is done by deploying the archive, which happens automatically
|
||
once a day, and the changes are only reflected when the =Version:=
|
||
header changes.
|
||
|
||
** Format
|
||
|
||
Each package should follow the ELPA packaging conventions, but there are
|
||
some differences due to the way the deployment script creates the packages
|
||
and the web-pages from this source code:
|
||
- Multi-file packages put the package metadata in the main =<pkg-name>.el= file
|
||
in the format used for single-file packages: the =<pkg-name>-pkg.el= file is
|
||
auto-generated from it.
|
||
- Every package should have both a =Version:= /and/ a =Maintainer:=.
|
||
- The =Version:= must be acceptable to =version-to-list=.
|
||
- The =URL:= header can be used to specify the home page
|
||
of the package, if it's maintained externally.
|
||
- A =News:= section (or "NEWS" file) can/should be used to list the
|
||
user-visible changes of each version.
|
||
- If you want some files to not be included in the tarball, you can
|
||
put a =.elpaignore= file in the root of your package directory, where you
|
||
can list patterns of files to ignore (this file is passed to =tar='s =-X=).
|
||
|
||
** Coding style
|
||
|
||
We do not impose a particular coding style on GNU ELPA packages, but of
|
||
course we recommend the coding style used in Emacs's own source code.
|
||
Furthermore we recommend the following:
|
||
- Use =cl-lib= rather than =cl= if at all possible.
|
||
- Use =lexical-binding= if at all possible.
|
||
- Try and fix the warnings emitted when compiling the package with a recent Emacs.
|
||
|
||
The Copyright notice should specify "Free Software Foundation, Inc." as
|
||
the copyright holder. Ensure that all the code has the proper copyright:
|
||
if it is not your own code, make sure the author has signed the relevant
|
||
copyright papers (for non-trivial contributions), and indicate the author
|
||
correctly in the commit.
|
||
|
||
** External branches
|
||
|
||
A copy of the code of every package is kept in the =elpa.git= repository
|
||
(not in the =main= branch) and if applicable should be sync'd with the
|
||
upstream every once in a while. This copy may include local changes,
|
||
although these should be kept to a minimum.
|
||
|
||
The copy of the code is not kept in =main= but in the
|
||
=externals/<pkg-name>= branch in the =elpa.git= repository.
|
||
[ Note: The name "externals/" is the result of an accident of history. ]
|
||
|
||
To add a new package, first add this =elpa.git= repository as a
|
||
new remote in your existing repository.
|
||
|
||
Then push a local branch to a new remote branch in =elpa.git=, named
|
||
=externals/<pkgname>=. For example:
|
||
|
||
#+begin_src shell
|
||
git push elpa <mybranch>:refs/heads/externals/<pkgname>
|
||
#+end_src
|
||
|
||
For example, let's say that you want to add =realgud-ipdb= which is currently
|
||
checked out in =$HOME/github/realgud-ipdb=:
|
||
|
||
#+begin_src shell
|
||
cd $HOME/github/realgud-ipdb
|
||
git remote add elpa ${USER}@git.sv.gnu.org:/srv/git/emacs/elpa.git
|
||
git push elpa master:refs/heads/externals/realgud-ipdb
|
||
#+end_src
|
||
|
||
Then edit the =elpa-packages= file as mentioned above, add the line
|
||
|
||
#+begin_src elisp
|
||
("realgud-ipdb" :url "https://github.com/realgud/realgud-ipdb")
|
||
#+end_src
|
||
|
||
and push that change to the =main= branch of =elpa=. After it's added to
|
||
the =elpa-packages= file, the package can be maintained just by
|
||
pushing changes to the =externals/<pkgname>= branch.
|
||
|
||
** Public incubation
|
||
|
||
If you want to develop a package publicly prior to its first release (to
|
||
benefit from others' feedback, primarily), but not in an external repo,
|
||
you have two choices:
|
||
- you can simply put =Version: 0= to indicate that this should not be
|
||
released yet.
|
||
- or you can push to an "ephemeral" branch -- subject to rebase and eventual
|
||
removal upon finishing merge -- for the duration of the incubation.
|
||
|
||
* Deployment
|
||
|
||
** To install all the packages "in place":
|
||
|
||
#+begin_src shell
|
||
make worktrees
|
||
make
|
||
#+end_src
|
||
|
||
This compiles and generates autoloads for all the packages in the
|
||
=packages/= directory. You can then add that directory, e.g. with:
|
||
|
||
#+begin_src elisp
|
||
(eval-after-load 'package
|
||
'(add-to-list 'package-directory-list ".../elpa/packages"))
|
||
#+end_src
|
||
|
||
** To deploy the package repository as a remotely-accessible archive:
|
||
|
||
#+begin_src shell
|
||
make build-all
|
||
#+end_src
|
||
|
||
This deploys the packages to the =archive/= subdirectory.
|
||
Unlike =make=, this makes a full copy of the packages, tars up
|
||
multi-file packages, and doesn't byte-compile any files.
|
||
|
||
** To access a deployed archive
|
||
|
||
To access the archive via HTTP, have a symlink (say) =/var/www/packages=
|
||
pointing to the =archive/= subdirectory, and set up Emacs with
|
||
|
||
#+begin_src elisp
|
||
(setq package-archives '(("new-elpa" . "https://foo.com/packages")))
|
||
#+end_src
|
||
|
||
You can also access the archive via normal file access. Such "local
|
||
archives" are useful for debugging:
|
||
|
||
#+begin_src elisp
|
||
(setq package-archives '(("local-elpa" . ".../elpa/archive")))
|
||
#+end_src
|
||
|
||
** Dependency management using GNU Guix
|
||
If you have the [[https://guix.gnu.org/][GNU Guix]] package manager installed, it can take care
|
||
of all the dependencies necessary for the ELPA build system to run.
|
||
You can initialise a shell session by running
|
||
|
||
#+begin_src sh
|
||
guix shell -m manifest.scm
|
||
#+end_src
|
||
|
||
** Notes specific to =elpa.gnu.org=
|
||
|
||
*** Periodic builds
|
||
The way things are set up on this machine, we refresh the archive by
|
||
a cron job. You can do it by hand by logging in (access set up by FSF
|
||
admins), and
|
||
|
||
#+begin_src shell
|
||
su - elpa
|
||
cd elpa
|
||
make build-all
|
||
#+end_src
|
||
|
||
Which makes a full archive deployment, as discussed above. The symlink
|
||
=/var/www/packages= points to the corresponding directory under
|
||
=/home/elpa/=.
|
||
|
||
*** Release and devel archives
|
||
elpa.gnu.org serves the gnu and nongnu package collections (roughly,
|
||
gnu requires FSF copyright assign, nongnu doesn't, but these terms are
|
||
not fully defined here).
|
||
|
||
In addition, elpa.gnu.org serves release and devel versions of each
|
||
package. The release version is defined by a change in the =Version:=
|
||
header of a package; the devel version is the latest commit.
|
||
|
||
The release version is accessed at:
|
||
|
||
gnu - https://elpa.gnu.org/packages/
|
||
nongnu - https://elpa.nongnu.org/nongnu/
|
||
|
||
The devel version is accessed at:
|
||
|
||
gnu - https://elpa.gnu.org/devel
|
||
nongnu - https://elpa.nongnu.org/nongnu-devel/
|
||
|
||
* License
|
||
This file is part of GNU Emacs.
|
||
|
||
GNU Emacs is free software: you can redistribute it and/or modify
|
||
it under the terms of the GNU General Public License as published by
|
||
the Free Software Foundation, either version 3 of the License, or
|
||
(at your option) any later version.
|
||
|
||
GNU Emacs is distributed in the hope that it will be useful,
|
||
but WITHOUT ANY WARRANTY; without even the implied warranty of
|
||
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
||
GNU General Public License for more details.
|
||
|
||
You should have received a copy of the GNU General Public License
|
||
along with GNU Emacs. If not, see <https://www.gnu.org/licenses/>.
|
||
|
||
|
||
#+STARTUP: showall
|
||
#+OPTIONS: num:1
|
||
#+AUTHOR: GNU ELPA Maintainers
|
||
#+EMAIL: emacs-devel@gnu.org
|
||
#+BEGIN_COMMENT
|
||
Local variables:
|
||
mode: org
|
||
paragraph-separate: "[ ]*$"
|
||
time-stamp-pattern: "4/#\\+DATE: %Y-%02m-%02d$"
|
||
end:
|
||
#+END_COMMENT
|