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.
prev 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
* 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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.