unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Jambunathan K <kjambunathan@gmail.com>
To: Chong Yidong <cyd@stupidchicken.com>
Cc: emacs-devel@gnu.org
Subject: Re: Packages + elpa.gnu.org
Date: Thu, 28 Oct 2010 13:25:34 +0530	[thread overview]
Message-ID: <81ocaesqdl.fsf@gmail.com> (raw)
In-Reply-To: <87y6a86muv.fsf@stupidchicken.com> (Chong Yidong's message of "Fri, 08 Oct 2010 23:55:52 -0400")


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.









      parent reply	other threads:[~2010-10-28  7:55 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-08 16:31 Packages + elpa.gnu.org Jambunathan K
2010-10-09  3:55 ` Chong Yidong
2010-10-10  5:00   ` Ted Zlatanov
2010-10-10  5:05     ` Chong Yidong
2010-10-12  7:19   ` Bastien
2010-10-12  9:57     ` Jambunathan K
2010-10-12 10:15       ` Bastien
2010-10-28  7:55   ` Jambunathan K [this message]

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.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=81ocaesqdl.fsf@gmail.com \
    --to=kjambunathan@gmail.com \
    --cc=cyd@stupidchicken.com \
    --cc=emacs-devel@gnu.org \
    /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.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).