emacs-devel
[Top][All Lists]
Advanced

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

Re: Packages + elpa.gnu.org


From: Jambunathan K
Subject: Re: Packages + elpa.gnu.org
Date: Thu, 28 Oct 2010 13:25:34 +0530
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.91 (windows-nt)

Hello Chong

Chong Yidong <address@hidden> 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.









reply via email to

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