From: Jambunathan K <kjambunathan@gmail.com>
To: Eric Schulte <schulte.eric@gmail.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: ELPA Howto
Date: Sun, 03 Oct 2010 09:53:23 +0530 [thread overview]
Message-ID: <811v87x5tw.fsf@gmail.com> (raw)
In-Reply-To: <878w2gihf3.fsf@gmail.com> (Eric Schulte's message of "Sat, 02 Oct 2010 12:22:08 -0600")
Hello Eric
"Eric Schulte" <schulte.eric@gmail.com> writes:
> Jambunathan K <kjambunathan@gmail.com> writes:
>
>> I managed to create an elpa compatible tar for orgmode. Recording here
>> what I did in the hope that it will be useful.
>>
>> Creating ELPA-compatible tar:
>>
>> 1. Add the enclosed changes to Makefile.
>> 2. Create an ELPA-compatible tarfile with
>> $ make TAG=20100930 elpa
>> 3. Copy the generated org-20100930.tar to the package server
>>
>
> That's great,
>
> and it looks like your Makefile patch even automates the process. I'd
> vote that this to be included into the core and that we begin supporting
> an elpa-installable version of org-mode tracking the latest named
> release. If possible I think it'd be great to add a git post-commit
> hook which could maintain a second elpa org-mode package tracking the
> latest git HEAD, although I'm not sure if this is possible and it may
> place overmuch burden on the repo.or.cz and the elpa servers.
>
One could host N latest snapshots and expunge the rest. The snapshots
could be published either daily or weekly etc etc. This could be hooked
to existing cron job.
Just publishing the snapshot itself would help problems surface
faster. The submitter of the problem could temporarily revert to an
earlier stable snapshot and wait till the next snapshot arrives (hoping
that his problem is addressed).
If a snapshot is 'truly' unstable maintainers could intervene and hand
publish the archive.
>>
>> ELPA Server-side setup:
>>
>
> I think we can ignore the server-side setup, since that should be
> handled by the elpa server at tromney or gnu.org. Is this correct?
>
> [...]
>
One could host packages on http://orgmode.org, In that case my notes
will serve as a good starting point.
Btw hosting the packages (also) on orgmode would give better control and
distribution.
>> An Observation:
>>
>> package.el generates an 'org-autoloads.el' as part of compilation and
>> loads the same as part of activation. This means that autoloads such as
>> 'org-agenda' gets served from the newly installed package while
>> non-autoloads like 'org-overview' still point to the old installation.
>>
>> This means that a restart of Emacs is necessary for the new changes to
>> take effect. I am not sure whether it is intended. But this behaviour
>> could surprise the user.
>>
>
> Noted, perhaps the user could somehow be instructed to run org-reload as
> part of the ELPA update process, although I believe even org-reload
> leaves some items un-re-initialized.
>
> Cheers -- Eric
>
>>
>> Jambunathan K.
>>
>> Attachments:
>>
>> X diff --git a/Makefile b/Makefile
>> X old mode 100644
>> X new mode 100755
>> X index 1c1f317..a84b62f
>> X --- a/Makefile
>> X +++ b/Makefile
>> X @@ -53,6 +53,9 @@ CP = cp -p
>> X # Name of the program to install info files
>> X INSTALL_INFO=install-info
>> X
>> X +
>> X +DOCSTRING = "Outline-based notes management and organizer"
>> X +
>> X ##----------------------------------------------------------------------
>> X ## BELOW THIS LINE ON YOUR OWN RISK!
>> X ##----------------------------------------------------------------------
>> X @@ -325,6 +328,14 @@ distfile:
>> X zip -r org-$(TAG).zip org-$(TAG)
>> X gtar zcvf org-$(TAG).tar.gz org-$(TAG)
>> X
>> X +elpa: install-info
>> X + $(MKDIR) org-$(TAG)
>> X + cp -r $(LISPFILES0) org-$(TAG)/
>> X + cp $(infodir)/dir org-$(TAG)
>> X + cp $(INFOFILES) org-$(TAG)
>> X + echo "(define-package \"org\" \"$(TAG)\" \"$(DOCSTRING)\")" > org-$(TAG)/org-pkg.el
>> X + tar cf org-$(TAG).tar org-$(TAG) --remove-files
>> X +
>> X makerelease:
>> X @if [ "X$(TAG)" = "X" ]; then echo "*** No tag ***"; exit 1; fi
>> X ${MAKE} distfile
>> X
>>
>> Jambunathan K.
>>
next prev parent reply other threads:[~2010-10-03 4:23 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-30 7:30 ELPA Howto Jambunathan K
2010-09-30 14:34 ` Jeff Horn
2010-10-02 18:22 ` Eric Schulte
2010-10-03 4:23 ` Jambunathan K [this message]
2010-10-04 1:28 ` Eric Schulte
2010-10-04 13:15 ` Eric Schulte
2010-10-20 16:37 ` Bastien
2010-10-20 19:44 ` Jambunathan K
2010-10-20 21:00 ` Eric Schulte
2010-10-04 13:39 ` Carsten Dominik
2010-10-04 17:29 ` Jambunathan K
2010-10-04 18:23 ` Jambunathan K
2010-10-05 2:13 ` Carsten Dominik
2010-10-05 10:11 ` Jambunathan K
2010-10-05 11:09 ` Version string (was Re: ELPA Howto) Jambunathan K
2010-10-08 10:38 ` Carsten Dominik
2010-10-08 11:45 ` Carsten Dominik
2010-10-09 5:27 ` Jambunathan K
2010-10-08 15:26 ` Jambunathan K
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=811v87x5tw.fsf@gmail.com \
--to=kjambunathan@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=schulte.eric@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).