emacs-elpa-diffs
[Top][All Lists]
Advanced

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

[elpa] elpa-admin 85d1352 04/12: * README: Incorporate changes from a co


From: Jonas Bernoulli
Subject: [elpa] elpa-admin 85d1352 04/12: * README: Incorporate changes from a commit in elpa.git:main
Date: Wed, 20 Oct 2021 18:51:56 -0400 (EDT)

branch: elpa-admin
commit 85d1352cf3e98d0579e4a3ef48f357fa2ad916cb
Author: Stefan Monnier <monnier@iro.umontreal.ca>
Commit: Jonas Bernoulli <jonas@bernoul.li>

    * README: Incorporate changes from a commit in elpa.git:main
    
    Incorporate most changes from the commit "Finalize the new master
    branch" (ee03829f90d25f62c2d36c5fef6f7b5eafb1040d).
    
    Both incarnations of README use the text before the first heading
    to talk about the containing branch/repository in way that makes it
    unsuitable for use in the other location.  The ported commit modifies
    that part and those changes are dropped here.
---
 README | 61 ++++++++++++++++---------------------------------------------
 1 file changed, 16 insertions(+), 45 deletions(-)

diff --git a/README b/README
index 558fbc7..c7a1a6e 100644
--- a/README
+++ b/README
@@ -209,15 +209,14 @@ Delete all the files generated by =make 
packages/[PKGNAME]=.
 This directory holds the package sources, with one subdirectory for
 each package.
 
-Each directory in here corresponds to a package, which can be
-either a single-file package or a multifile package.
+Each directory in here corresponds to a package.
 
 A nightly cron job 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
+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)
@@ -273,7 +272,7 @@ your changes for you.  You should probably also subscribe to
 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 (1-file) package as =packages/<pkg-name>/<pkg-name>.el.=
+*** 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
@@ -285,9 +284,9 @@ For some examples, see 
[[https://www.gnu.org/software/emacs/manual/html_node/eli
     (info "(elisp) Simple Packages")
 #+end_src
 
-*** Add a multi-file package as a directory: =packages/<pkg-name>=
+*** Add a multi-file package as a directory
 
-It needs to have a file named =packages/<pkg-name>/<pkg-name>.el= which 
follows the
+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]]
@@ -334,10 +333,6 @@ and the web-pages from this source code:
   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.
-- The =Package-Type:= header can be used to force the type of package
-  created (can be either =simple= for single-file packages or =multi= for
-  tarballs).  By default the type is decided based on whether there are
-  several Elisp files in the source.
 - 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=).
@@ -359,20 +354,15 @@ correctly in the commit.
 
 ** External branches
 
-The above instructions are enough to add regular packages, those that
-are maintained primarily here in the repository and are fairly small.
-The instructions below are for those maintainers who prefer to use a dedicated
-repository or branch for the package or for largish packages.
-
-In any case, a copy of the code is kept in the =elpa.git= repository
-(not in the default branch) and should be sync'd with the
+A copy of the code of every package is kept in the =elpa.git= repository
+(not in the default 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 the default branch but in the
 =elpa/<pkg-name>= branch in the =elpa.git= repository.
 
-To add a new external package, first add this =elpa.git= repository as a
+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
@@ -452,37 +442,18 @@ This compiles and generates autoloads for all the 
packages in the
 
 ** To deploy the package repository as a remotely-accessible archive:
 
-The deployment process creates sibling directories, so start by creating
-a clean directory to work in:
-
 #+begin_src shell
-   mkdir elpa ; cd elpa
+   make build-all
 #+end_src
 
-The above step is optional, but recommended.
-
-#+begin_src shell
-   git -c fetch.fsckObjects=false clone .../elpa
-   (cd elpa; git clone .../emacs)    #If you want to generate :core packages.
-   mkdir build
-   cd build
-   (cd ../elpa; git log --format=%H | tail -n 1) >.changelog-witness
-   ln -s ../elpa/admin
-   ln -s ../elpa/GNUmakefile
-   admin/update-archive.sh
-#+end_src
-
-This deploys the packages to the =staging/= directory (sibling of =build=).
+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.
 
-The =fetch.fsckObjects= setting works around a glitch in the ELPA
-repository.  (See [[https://debbugs.gnu.org/22690][Bug#22690]].)
-
 ** To access a deployed archive
 
 To access the archive via HTTP, have a symlink (say) =/var/www/packages=
-pointing to =DEST/packages=, and set up Emacs with
+pointing to the =archive/= subdirectory, and set up Emacs with
 
 #+begin_src elisp
   (setq package-archives '(("new-elpa" . "https://foo.com/packages";)))
@@ -492,7 +463,7 @@ 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/packages")))
+  (setq package-archives '(("local-elpa" . ".../elpa/archive")))
 #+end_src
 
 ** Notes specific to =elpa.gnu.org=
@@ -502,13 +473,13 @@ 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/build
-   admin/update-archive.sh
+   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 staging package directory under
+=/var/www/packages= points to the corresponding directory under
 =/home/elpa/=.
 
 * License



reply via email to

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