Packages + elpa.gnu.org

Packages + elpa.gnu.org

[Jambunathan K]

There is some interest in getting Orgmode (stable release + daily build
) in to http://elpa.gnu.org/packages.

In this context:

1. Who acts as a janitor for the elpa repository.

2. How does one upload packages - a mail drop to the maintainer, remote
   update from within emacs - scp, ftp etc etc . (Is package-x.el's
   package-upload-buffer and related configuration documented
   somewhere.)

3. Does the package manager expect that builtin packages be versioned in
   a special way. For example, can the stable release be called 7.0.1
   while a daily snapshot be called 20101008?

4. Any general guidelines on what packages would be accepted there and
   how often an update can happen. Are daily snapshots allowed.

Jambunathan K.

Re: Packages + elpa.gnu.org

[Chong Yidong]

Jambunathan K <kjambunathan@gmail.com> writes:

> 1. Who acts as a janitor for the elpa repository.

Me.  Ted Zlatanov also has access.  We've both been pretty busy on other
parts of Emacs lately, though, so there are a couple of packages that
are in the pipeline for uploading (including AuCTEX).

> 2. How does one upload packages - a mail drop to the maintainer, remote
>    update from within emacs - scp, ftp etc etc . (Is package-x.el's
>    package-upload-buffer and related configuration documented
>    somewhere.)

Probably the easiest way to set this up is for someone on the org-mode
team to upload the dailies to a server somewhere on the web, giving the
tarball a deterministic name.  Then, someone (probably me) will have to
set up a cron job on elpa.gnu.org to check for that tarball each day,
download it, and run `package-upload-file' to add it to the repository.

> 3. Does the package manager expect that builtin packages be versioned in
>    a special way. For example, can the stable release be called 7.0.1
>    while a daily snapshot be called 20101008?

The package manager uses the most recent version of a package, as
defined by `version-list-<'.

> 4. Any general guidelines on what packages would be accepted there and
>    how often an update can happen. Are daily snapshots allowed.

The main requirement is for package copyrights to be FSF assigned.  I
think providing dailies is fine.

Re: Packages + elpa.gnu.org

[Ted Zlatanov]

On Fri, 08 Oct 2010 23:55:52 -0400 Chong Yidong <cyd@stupidchicken.com> wrote: 

CY> Jambunathan K <kjambunathan@gmail.com> writes:
>> 2. How does one upload packages - a mail drop to the maintainer, remote
>> update from within emacs - scp, ftp etc etc . (Is package-x.el's
>> package-upload-buffer and related configuration documented
>> somewhere.)

CY> Probably the easiest way to set this up is for someone on the org-mode
CY> team to upload the dailies to a server somewhere on the web, giving the
CY> tarball a deterministic name.  Then, someone (probably me) will have to
CY> set up a cron job on elpa.gnu.org to check for that tarball each day,
CY> download it, and run `package-upload-file' to add it to the repository.

I suggested using a Bazaar repo for this.  It doesn't have to be as
elaborate as Ubuntu's setup but it could at least help us track uploads
and history.  Chong, did you want to go with that proposal?

Ted

Re: Packages + elpa.gnu.org

[Chong Yidong]

Ted Zlatanov <tzz@lifelogs.com> writes:

> CY> Probably the easiest way to set this up is for someone on the org-mode
> CY> team to upload the dailies to a server somewhere on the web, giving the
> CY> tarball a deterministic name.  Then, someone (probably me) will have to
> CY> set up a cron job on elpa.gnu.org to check for that tarball each day,
> CY> download it, and run `package-upload-file' to add it to the repository.
>
> I suggested using a Bazaar repo for this.  It doesn't have to be as
> elaborate as Ubuntu's setup but it could at least help us track uploads
> and history.  Chong, did you want to go with that proposal?

If you're willing to help implement it, sure.  As I said to you before,
the main advantage of the existing package uploading system is that it
exists.

Re: Packages + elpa.gnu.org

[Bastien]

Hi Chong,

Chong Yidong <cyd@stupidchicken.com> writes:

> Probably the easiest way to set this up is for someone on the org-mode
> team to upload the dailies to a server somewhere on the web, giving the
> tarball a deterministic name.  

http://orgmode.org/org-latest.tar.gz is daily built.  Does that help?

-- 
 Bastien

Re: Packages + elpa.gnu.org

[Jambunathan K]

Hello Bastien

Bastien <bzg@altern.org> writes:

> Hi Chong,
>
> Chong Yidong <cyd@stupidchicken.com> writes:
>
>> Probably the easiest way to set this up is for someone on the org-mode
>> team to upload the dailies to a server somewhere on the web, giving the
>> tarball a deterministic name.  
>
> http://orgmode.org/org-latest.tar.gz is daily built.  Does that help?

This is a old/non-ELPA tarball. 

Recently, I had introduced a new Makefile target to Orgmode repo that
would build ELPA-compatible tarballs. There is also this issue of
versioning that is yet to be resolved by Carsten.

Jambunathan K.

Re: Packages + elpa.gnu.org

[Bastien]

Jambunathan K <kjambunathan@gmail.com> writes:

>> http://orgmode.org/org-latest.tar.gz is daily built.  Does that help?
>
> This is a old/non-ELPA tarball. 

Okay.

> Recently, I had introduced a new Makefile target to Orgmode repo that
> would build ELPA-compatible tarballs. 

Can you send me this Makefile in private, so that I use it to create an
ELPA-compatible daily tarball?

> There is also this issue of versioning that is yet to be resolved by
> Carsten.

Ok.  Please keep me posted about this.

-- 
 Bastien

Re: Packages + elpa.gnu.org

[Jambunathan K]

Hello Chong

Chong Yidong <cyd@stupidchicken.com> writes:

>> 3. Does the package manager expect that builtin packages be versioned in
>>    a special way. For example, can the stable release be called 7.0.1
>>    while a daily snapshot be called 20101008?
>
> The package manager uses the most recent version of a package, as
> defined by `version-list-<'.
>

For a builtin package which is actually a bunch of files how and
wherefrom the package manager picks up the name and version number. I am
specifically interested in Orgmode.

>> 4. Any general guidelines on what packages would be accepted there and
>>    how often an update can happen. Are daily snapshots allowed.
>
> The main requirement is for package copyrights to be FSF assigned.  I
> think providing dailies is fine.

Since dailies are permitted, I believe it would be a good idea to
recognize - if not by specification atleast by convention - multiple
streams of releases.

For the sake of discussion, orgmode one can have these two packages
simultaneously in the repo.

org/stable-x.y.z.tar and org/unstable-x.y.z.tar

Here stable and unstable are the two 'streams' for the package and '/'
is the separator.

I see the following advantages:

1. From the user side, there is no confusion on what he is setting-up
   himself against.

2. From the maintainer's side, the two packages could be versioned
   separately. For example, the stable package could use a 7.x scheme
   and the unstable package could do a '20101028' versioning
   scheme. More importantly, M-x package-upload-file wouldn't knock off
   stable entry in archive-contents favoring a daily release which has a
   higher version number.

One important side-effect of granting 'streams' an official stauts would
be that that sorting by name would sort really by name component of the
package as the primary key and 'stream' component as a secondary
key. This is very necessary as there would be no way a random package
can intersperse between org/stable and org/unstable by mere choice of
name.

Speaking of package manager being intelligent, when I do M-x
list-packages I am inclined to think the list is sorted in the following
order - <package status, package name> - with package status being the
primary key.

The problem is I get 3 entries for orgmode - available, installed,
obsolete
- that are far separated from each other. 

Any ways I can filter and sort these entries? Can this be captured in
the documentation.

I welcome any ideas or suggestions.

Jambunathan K.