Re: [Orgmode] ELPA Howto

[Jambunathan K]

Hello Eric

"Eric Schulte" <address@hidden> writes:
> Jambunathan K <address@hidden> 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.
>>