CVS is the `released version'

CVS is the `released version'

[Robert J. Chassell]

Remember, for many people, but not for many moderns, CVS provides the
`released version' of GNU Emacs.  It is the prime version used by
those who contribute.  It is not a binary that cannot be changed.
Once in a while, development needs to be frozen while bugs are fixed.

Since more and more people are coming to think of or are forced to use
big numbered releases and eschew the daily releases, they view a delay
between one big numbered release and another as bad.  But those who
enjoy daily releases hardly notice.

I suspect we are seeing a conflict between cultures: on the one hand,
those who install a new release of GNU Emacs every day or almost every
day and, on the other hand, those who look for big numbered releases,
such as that from Emacs 21 to Emacs 22.
    
The world is tending towards those who look for big numbered releases
even though most contributions are small.

-- 
    Robert J. Chassell                          GnuPG Key ID: 004B4AC8
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc

Re: CVS is the `released version'

[Thomas Hühn]

"Robert J. Chassell" <bob@rattlesnake.com> writes:

> Remember, for many people, but not for many moderns, CVS provides the
> `released version' of GNU Emacs.  It is the prime version used by

Really? Under all circumstances?

It has worked over the last months and years quite well, but do you
really want to recommend people to use CVS Emacs when heavy development
is under way? Say, when those unicode-2 branch gets merged?

Thomas

Re: CVS is the `released version'

[Robert J. Chassell]

    It has worked over the last months and years quite well, but do you
    really want to recommend people to use CVS Emacs when heavy development
    is under way? Say, when those unicode-2 branch gets merged?

Then I recommend people use an older version.  That is what the

    cvs update -D "10 days ago"

command is for.

David Kastrup <dak@gnu.org> says 

   ... A release is a point of stability, one where one tries to make
   reasonably sure that the overall consistency (of packages working
   together and with the core, and of code and documentation) is in
   reasonable shape, for whoever happens to use the software.

That presumes most people are not going to contribute, which may well
be true.  The view may not be a presumption, it may be an accurate
description.  But the issue may be one of morals, not evidence.  The
argument may be that people should find it easy to contribute.

In any case, David Kastrup's view does not reflect the experience
those who I have been calling (to myself) `the ancients'.  RMS is a
wonderful example of them, since he first wrote Emacs in the 1970s and
does not change habits if he can keep them.  (I am `ancient', too -- I
remember hearing on the radio that Sputnik was launched and being
amazed that the announcer had to explain that it was an `artificial
moon' -- but that is a totally different story.)


   But never releasing anything for which one has at least some
   inclination to stand behind it and call it "this is as good as it
   gets right now" is not a good idea either, in my book.

The point I am trying to make is that some people think Emacs is
released every day.  That is the opposite of `never releasing
anything'.  Often enough, but not always, you can use those releases.
But others do not think of those updates as releases.

-- 
    Robert J. Chassell                          GnuPG Key ID: 004B4AC8
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc

Re: CVS is the `released version'

[Thomas Hühn]

"Robert J. Chassell" <bob@rattlesnake.com> writes:

>     It has worked over the last months and years quite well, but do you
>     really want to recommend people to use CVS Emacs when heavy development
>     is under way? Say, when those unicode-2 branch gets merged?
>
> Then I recommend people use an older version.  That is what the
>
>     cvs update -D "10 days ago"
>
> command is for.

Are you willing to state on the Emacs web site which day's Emacs is
"good enough" for regular use? That must be updated regularly, of
course.

There are quite a few more Emacs users out there than those who read CVS
commits and want to/can decide themselves, whether one day's Emacs is
good.

Such expectations towards users are unrealistic. At best.

Thomas

Re: CVS is the `released version'

[Robert J. Chassell]

   Are you willing to state on the Emacs web site which day's Emacs is
   "good enough" for regular use?  That must be updated regularly, of
   course.

The issue is not whether I am willing, the issue is whether an expert
would be willing.  I think it would be hard.  As David Kastrup
<dak@gnu.org> says

    It takes expertise to know which might be the best date.

There is no doubt that nowadays

    There are quite a few more Emacs users out there than those who
    read CVS commits ...

That is true.  I think the real question is moral.

We live in an age of professionals.  Often they know more, a huge
amount more, than enthusiastic amateurs.  Professional programmers
know more about programming than people who type reports about
something else.

The moral issue is whether amateurs should give up power to
professionals?

When amateurs give way to professionals, willy-nilly, they promote a
scalable, but awkward social form which gives those on the top more
power than those on the bottom.  Consider RMS and GNU Emacs as
examples.

The alternative, which I know RMS seeks even though he is poor at it,
is a world in which professionals and amateurs cooperate.

That does not mean that professionals do not do their jobs (unless you
presume that professionals are always on top).  But it does mean a
different model.

As for specific points:

    > That presumes most people are not going to contribute, which may
    > well be true.

    I don't see this at all ...

Most of the people I know who are still using Emacs 21 do not
contribute.  Often they don't know how to.

As far as I can see, contribution involves interest and attention.
Most people I know are no more interested in software development than
they are in road construction.  (I think they ought to be interested
in both, but that is another issue.)  Their attention is directed
towards other people or towards non-peopled activities that have
nothing to do with either software development or road construction.

    > The argument may be that people should find it easy to
    > contribute.

    And they can't contribute if there contributions never end up on a
    user's computer.

But if the contribution does end up on a user's computer ... that is
the moral argument.  The moral position is that users fetch a current
release.  Except for instabilities which a professional detects (and
talks about), the release for users will be today's or yesterdays, or
since you may not restart Emacs very often, last month's.

I am not saying that GNU Emacs fits this model.  For one, no good
professional tells amateurs that "today's update is bad" for them (but
possibly good for professionals).  However, I am saying that the claim
that `contributions never end up on a user's computer' is true only if
you presume that users fetch or are forced to fetch big numbered
releases.

    > But others do not think of those [i.e., daily] updates as releases.

    Word games don't help in the current situation.

It is not a word game.

In order to avoid problems, many previously hierarchical
organizations, purely hierarchical, have instituted `matrix
management' and the like.  (Most of the solutions, I think, are crazy;
but they indicate felt problems.)  In the United States, I frequently
see references to `pointy haired bosses'.  These are references to a
character in a cartoon.  Among other things, that cartoon attacks
professional managers because they cannot contribute technically about
that which they know nothing.  Nonetheless, such bosses had to have
known how to become managers.

--
    Robert J. Chassell                          GnuPG Key ID: 004B4AC8
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc

Re: CVS is the `released version'

[David Kastrup]

"Robert J. Chassell" <bob@rattlesnake.com> writes:

> As for specific points:
>
>     > That presumes most people are not going to contribute, which may
>     > well be true.
>
>     I don't see this at all ...
>
> Most of the people I know who are still using Emacs 21 do not
> contribute.  Often they don't know how to.

I was talking about "That presumes".  I don't see at all the
connection.

-- 
David Kastrup

Re: CVS is the `released version'

[David Kastrup]

"Robert J. Chassell" <bob@rattlesnake.com> writes:

>     It has worked over the last months and years quite well, but do you
>     really want to recommend people to use CVS Emacs when heavy development
>     is under way? Say, when those unicode-2 branch gets merged?
>
> Then I recommend people use an older version.  That is what the
>
>     cvs update -D "10 days ago"
>
> command is for.

Replacing one random date with another is not helping any.  It takes
expertise to know which might be the best date.  A release is
something where the developers as a set of experts agrees.  This
developer knowledge can't be reliably replaced with dice.

It is also hampering development if developers feel compelled to keep
Emacs CVS trunk in a workable state at all times.

> David Kastrup <dak@gnu.org> says 
>
>    ... A release is a point of stability, one where one tries to
>    make reasonably sure that the overall consistency (of packages
>    working together and with the core, and of code and
>    documentation) is in reasonable shape, for whoever happens to use
>    the software.
>
> That presumes most people are not going to contribute, which may
> well be true.

I don't see this at all and don't have the slightest idea why you
would think such a thing.

> The view may not be a presumption, it may be an accurate
> description.  But the issue may be one of morals, not evidence.  The
> argument may be that people should find it easy to contribute.

And they can't contribute if there contributions never end up on a
user's computer.

> In any case, David Kastrup's view does not reflect the experience
> those who I have been calling (to myself) `the ancients'.  RMS is a
> wonderful example of them, since he first wrote Emacs in the 1970s
> and does not change habits if he can keep them.

You should be careful about your examples.  RMS has (quite prudently)
changed his working style on Emacs and the development style several
times.  It is now maintained in CVS, and the CVS has been made open to
public, too.  And he is about to change the habits again, as can be
witnessed by his call for a new Emacs maintainer.

So Richard is quite aware himself when it becomes infeasible to keep
his habits.

>    But never releasing anything for which one has at least some
>    inclination to stand behind it and call it "this is as good as it
>    gets right now" is not a good idea either, in my book.
>
> The point I am trying to make is that some people think Emacs is
> released every day.  That is the opposite of `never releasing
> anything'.  Often enough, but not always, you can use those
> releases.

Because they aren't releases.

> But others do not think of those updates as releases.

Word games don't help in the current situation.

-- 
David Kastrup

Re: CVS is the `released version'

[Andrea Russo]

David Kastrup <dak@gnu.org> writes:

>> The view may not be a presumption, it may be an accurate
>> description.  But the issue may be one of morals, not evidence.  The
>> argument may be that people should find it easy to contribute.
>
> And they can't contribute if there contributions never end up on a
> user's computer.

My (very tiny) contributions to GNU Emacs were possible because of the
strong incentive to have the shiny and new features only present in
Emacs CVS (actually I use emacs--cvs--0 Arch archive from Miles).  And
I consider myself an Emacs "user", not a developer.

Sure, one is always free to have development versions of programs
installed in his computer to be able to contribute, but having
incentives is very important imho to start being involved.

The tremendous extensibility of Emacs trough elisp is very helpful to
become a contributor, but I think that bluring the user/developer line
also by having users running the development version (or at least
being able to switch from released to development version in a very
easy way) could be a great goal to achieve.

Just my 2 cents.

Regards,
Andrea.

--
Do not worry about your difficulties in mathematics;
I can assure you that mine are still greater.

Re: CVS is the `released version'

[Thomas Hühn]

Andrea Russo <rastandy@inventati.org> writes:

> The tremendous extensibility of Emacs trough elisp is very helpful to
> become a contributor, but I think that bluring the user/developer line
> also by having users running the development version (or at least
> being able to switch from released to development version in a very
> easy way) could be a great goal to achieve.

If you want "normal" users to use Emacs-CVS, you need to provide regular
snapshots and -- much more important -- you must never ever break Emacs
on the trunc during development.

Thomas

Re: CVS is the `released version'

[David Kastrup]

"Robert J. Chassell" <bob@rattlesnake.com> writes:

> Remember, for many people, but not for many moderns, CVS provides the
> `released version' of GNU Emacs.  It is the prime version used by
> those who contribute.  It is not a binary that cannot be changed.
> Once in a while, development needs to be frozen while bugs are fixed.
>
> Since more and more people are coming to think of or are forced to use
> big numbered releases and eschew the daily releases, they view a delay
> between one big numbered release and another as bad.  But those who
> enjoy daily releases hardly notice.
>
> I suspect we are seeing a conflict between cultures: on the one hand,
> those who install a new release of GNU Emacs every day or almost every
> day and, on the other hand, those who look for big numbered releases,
> such as that from Emacs 21 to Emacs 22.
>     
> The world is tending towards those who look for big numbered releases
> even though most contributions are small.

I can't find I agree even remotely.  A release is a point of
stability, one where one tries to make reasonably sure that the
overall consistency (of packages working together and with the core,
and of code and documentation) is in reasonable shape, for whoever
happens to use the software.

There are development phases where most changes are incremental and
where it becomes a reasonable operation to track the trunk.  The Linux
kernel development has changed its mode of operation and its
definition of "stable" and "release" a lot over the years.  Emacs
development has pretty much stalled in release anticipation, leading
to a version where one could have made a release pretty much anytime
in the last two years and have the users get something _better_ than
they are using now, and the developers a new point from which to
continue.

Architectural changes have not happened in the last few years, even
though some architectures have had a lot of problems shaken out
(Windows and MacOSX, two proprietary platforms).  Technologies like
emacs-unicode2, and even somewhat less radical changes like multitty
are not fit to be taken in mid-stride.  While the emacs-unicode2
branch is currently comparatively stable, this is not an accident but
the result of a _lot_ of duplicate work over years because of the
pent-up release.

There are no easy answers: XEmacs has decoupled packages and releases
them separately and often.  I am not convinced of the results: there
appears to be quite some bit rot happening, the beta core has been
unstable for a large time, anyway, and the packages are often not
updated or fixed for long amounts of time.

But never releasing anything for which one has at least some
inclination to stand behind it and call it "this is as good as it gets
right now" is not a good idea either, in my book.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: CVS is the `released version'

[Chong Yidong]

"Robert J. Chassell" <bob@rattlesnake.com> writes:

> Remember, for many people, but not for many moderns, CVS provides the
> `released version' of GNU Emacs.

The vast majority of users of any software (not just Emacs) use
released versions, not CVS.  Since one of the motivations for
contributing to free and open source software (especially for a
volunteer) is to help people, it's obviously a better idea to spend
one's time working on a project that actually makes releases, since
you would be helping more people.

Re: CVS is the `released version'

[Ken Manheimer]

On 5/9/07, Robert J. Chassell <bob@rattlesnake.com> wrote:

> Remember, for many people, but not for many moderns, CVS provides the
> `released version' of GNU Emacs.  It is the prime version used by
> those who contribute.  It is not a binary that cannot be changed.
> Once in a while, development needs to be frozen while bugs are fixed.
>
> Since more and more people are coming to think of or are forced to use
> big numbered releases and eschew the daily releases, they view a delay
> between one big numbered release and another as bad.  But those who
> enjoy daily releases hardly notice.
>
> I suspect we are seeing a conflict between cultures: on the one hand,
> those who install a new release of GNU Emacs every day or almost every
> day and, on the other hand, those who look for big numbered releases,
> such as that from Emacs 21 to Emacs 22.
>
> The world is tending towards those who look for big numbered releases
> even though most contributions are small.

actually, incremental updates to end users are a *burgeoning* trend,
in certain circles.  "cloud" software, where you run a client that's
obtained from the network, delivers updates any time the managers
decide to release  revisions.  this is not as exotic as it sounds -
we're talking web applications like gmail, yahoo maps, even open
office and firefox have a self-update mode.  (i just opened my
firefox-based google notebook to discover a new look that incorporates
some features which address some of my former peeves.)

that self-update mode even applies to whole operating systems, where
the os vendor can convince their customers it has to be that way - can
you say, "security updates"?, and stealthy dissemination of
property-rights restrictions?

there is a diffference with CVS updates that is much more important
than push-pull, however.

the network-released incremental updates are managed as deliberate,
measured releases, and not just the set of any updates.  it takes
attention - time and discretion - to distinguish the development
frontier from the release frontier, though both can be incremental.  a
"stable"-ish branch in a code versioning arrangement may be a closer
aproximation, certainly more so than the trunk.

i like the idea of an incremental release mechanism for emacs.  but it
needs to be done right - i think xemacs network-based packages update
system doesn't quite do it, though it might be a step in the right
direction.
-- 
ken
http://myriadicity.net

Re: CVS is the `released version'

[Stefan Monnier]

> I like the idea of an incremental release mechanism for Emacs.  But it
> needs to be done right - I think XEmacs network-based packages update
> system doesn't quite do it, though it might be a step in the right
> direction.

I'm not sure if unbundling packages can be a help, but as a developper,
I like the fact that I can go and change a bunch of packages in-step without
worrying about backward compatibility (actually, I do have to worry about it
for those packages which are maintained by people who also distribute it as
a separate package and I find it to "constrain my style").

So I'd rather keep the monolithic package, but just have a stable branch
which is fairly liberally open to contributions, so long as those are
non-disruptive.  I guess by "non-disruptive" I mean that the patches are
either "obviously safe" or have an obviously limited impact so that even if
they introduce bugs, these bugs should have a limited impact.  I'm thinking
of bugs such as incorrect indentation or highlighting, as opposed to a crash
or a data corruption.  Also it's important those bugs be fixable in a rather
straightforward way: i.e. no installation of a patch with non-trivial
dependencies such that reverting it might be painful.


        Stefan

Re: CVS is the `released version'

[Richard Stallman]

I don't like the idea of having a package system for Emacs.  First of all,
it clearly is not needed.  Second, it would invite programmers to put
a lot of work into a mechanism instead of putting it into improvements
in what Emacs can actually do.

Re: CVS is the `released version'

[joakim]

Richard Stallman <rms@gnu.org> writes:

> I don't like the idea of having a package system for Emacs.  First of all,
> it clearly is not needed.  Second, it would invite programmers to put
> a lot of work into a mechanism instead of putting it into improvements
> in what Emacs can actually do.

Tom Tromey posted a simple implementation of a package system to
emacs.sources recently. It works fairly well, so the time is already
invested.

IMHO such a system is very useful for packages outside of the emacs
core, and it would be nice if package.el could be inside the core so
external packages could be easily installed by users.

Compared with systems like Eclipse, installing an emacs package
consists of some fairly boring obviously automatable steps. (like
hunting for the package, downloading in the right dir, entering the
correct invocation in .emacs, etc...)


-- 
Joakim Verona

Re: CVS is the `released version'

[Richard Stallman]

    Tom Tromey posted a simple implementation of a package system to
    emacs.sources recently. It works fairly well, so the time is already
    invested.

I wish that were true, but most of the work of installing a package
system is making everything _use_ it.

    Compared with systems like Eclipse, installing an emacs package
    consists of some fairly boring obviously automatable steps. (like
    hunting for the package,

I don't see how any code installed in Emacs could save you the need
for that.

			     downloading in the right dir, entering the
    correct invocation in .emacs, etc...)

Since just loading the files is not supposed to change Emacs
functionality, I think the need for this cannot be avoided.

So that doesn't leave much good that a package system could do.

Re: CVS is the `released version'

[joakim]

Richard Stallman <rms@gnu.org> writes:

>     Tom Tromey posted a simple implementation of a package system to
>     emacs.sources recently. It works fairly well, so the time is already
>     invested.
>
> I wish that were true, but most of the work of installing a package
> system is making everything _use_ it.

Everyone doesnt have to use it, just several providers of interesting packages.
And also, a repository maintainer might choose to enter a package into
the system withouth explicit work from a package author.

>     Compared with systems like Eclipse, installing an emacs package
>     consists of some fairly boring obviously automatable steps. (like
>     hunting for the package,
>
> I don't see how any code installed in Emacs could save you the need
> for that.

It can be easier to find a package through an emacs interface, rather
than google.

> 			     downloading in the right dir, entering the
>     correct invocation in .emacs, etc...)
>
> Since just loading the files is not supposed to change Emacs
> functionality, I think the need for this cannot be avoided.

A package system can give a user help to install the necesessary
invocation into .emacs, given the users consent, similar to "Customize".

> So that doesn't leave much good that a package system could do.

I do feel there is things a package system can do for Emacs. I base
this on examples like the "Eclipse" editor, and the "Smart" rpm
package manager. 

-- 
Joakim Verona

Re: CVS is the `released version'

[Ryan Yeske]

   I wish that were true, but most of the work of installing a package
   system is making everything _use_ it.

There are many people who are not necessarily emacs lisp hackers but
would be willing and able to prepare third party elisp packages from
existing sources.  I believe that the various free operating system
projects are able to find the resources for similar work for their
package management systems without draining the resources of the
hackers actually working on the development of the packages
themselves.

   I don't see how any code installed in Emacs could save you the need
   for that.

In my quick test of package.el, I was able to install and run a
package in 1/10th the time it would have taken to find, download and
install it manually.  For a package with dependencies on other
package libraries, the time/effort benefit would be even greater.

   Since just loading the files is not supposed to change Emacs
   functionality, I think the need for this cannot be avoided.

Having the package system install the file and setup autoloads in
.emacs will not itself change emacs functionality, but will save the
user a tremendous amount of tedious work.

Ryan

Re: CVS is the `released version'

[David Kastrup]

Ryan Yeske <rcyeske@gmail.com> writes:

>    I wish that were true, but most of the work of installing a package
>    system is making everything _use_ it.
>
> There are many people who are not necessarily emacs lisp hackers but
> would be willing and able to prepare third party elisp packages from
> existing sources.

This statement is in stark contrast to my personal experiences.  The
AUCTeX package, a pretty important editing mode for TeX-based formats,
has been lagging behind seriously in the XEmacs package system for the
last five years or so.  While a single person finally was found who
would _try_ keeping it more or less up to date, this has not really
worked out reasonably well.  As a result, the current version as
distributed by XEmacs remains terribly outdated.

The XEmacs package system basically consists of several pieces of
policy: a package layout which packages have to obey, a central
package repository where packages are checked in via CVS and built,
servers populated from this repository and mirrored.

AUCTeX is a complex package interacting with quite a few external
components.  It has an autoconf-based build procedure that can cater
for a lot of constellations and can be employed to tailor-fit AUCTeX
to a particular TeX environment.  It also runs on several different
Emacs variants.

The build infrastructure of AUCTeX is flexible enough to create an
XEmacs package, and indeed we distribute ready-built packages from the
AUCTeX download area.

XEmacs policies, however, prohibit the distribution of packages not
built with the XEmacs-specific build tools.

So basically the third-party maintainer has the grateful task of
taking the AUCTeX source package, rip Makefile and other generic build
structure from it, add definition files and stuff for the XEmacs
package build process and massage them until the output is just like
what AUCTeX upstream distributes as an XEmacs package in the first
place.

> I believe that the various free operating system projects are able
> to find the resources for similar work for their package management
> systems without draining the resources of the hackers actually
> working on the development of the packages themselves.

Please don't make the mistake of comparing the developer numbers on
operating system packagers (and the amount of work done) with those on
Emacs.

Most free operating systems which are not just packaging of other's
technology have one active work area: the packaging infrastructure.

In contrast, we Emacs hackers actually mostly work _coding_ stuff, not
arranging it.  And still our manpower is quite less.

Now the theory might be that once packaging becomes the mot du jour,
lots of non-developers will package lots of great things.

The problem is that there are not that many great things around that
are not already integrated into Emacs.

So a package system that comes with lots and rules and policies like
the XEmacs system does, is rather something that blocks inclusion of
good code and/or leads to its bit rot.

We would not want to go down the same path.  This does not rule out
package systems per se, but they are certainly not the panacea that
can offset bit rot, overpolicing and general indifference.  For
AUCTeX, the XEmacs package system has shown to be a roadblock for
getting uptodate packages to the users.  Not because of the structure
of such a package (which is a tar.gz file organized to drop into the
XEmacs package tree, with few additional files in fixed relative
places, like one defining package version and identification, one
containing customizable variables so that you don't need to preload
the package in order to customize it, one containing the autoloads,
one containing a list of all files so that the package can be removed
again if necessary, and some files like info files that are dropped in
standard places): that is actually useful.

But the whole _mandatory_ infrastructure (only available via anonymous
CVS and not conducive for creating Emacs packages) which one _has_ to
employ to create such a package (which has to be checked _into_ CVS so
that this venue is only open to registered XEmacs developers) so that
it will be accepted for distribution by the central servers (there is
no such thing as package specific repositories) is not really
conducive to producing output unless one is quite dedicated to XEmacs
specific development.

With all that policing, the administrative burden is actually more
than getting some Lisp file accepted into the Emacs core tree.

The advantage is just one of decoupled updates of centrally organized
packages to the centrally organized core.

I doubt that this could not equally well be achieved with a policy of
more frequent releases from a release branch.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: CVS is the `released version'

[Ralf Angeli]

* David Kastrup (2007-05-13) writes:

> The advantage is just one of decoupled updates of centrally organized
> packages to the centrally organized core.
>
> I doubt that this could not equally well be achieved with a policy of
> more frequent releases from a release branch.

It does not cater for people who think that over 100MB is an obscene
size for an editor.  It is quite lean for a desktop environment, though.

-- 
Ralf

Re: CVS is the `released version'

[David Kastrup]

Ralf Angeli <angeli@caeruleus.net> writes:

> * David Kastrup (2007-05-13) writes:
>
>> The advantage is just one of decoupled updates of centrally organized
>> packages to the centrally organized core.
>>
>> I doubt that this could not equally well be achieved with a policy of
>> more frequent releases from a release branch.
>
> It does not cater for people who think that over 100MB is an obscene
> size for an editor.  It is quite lean for a desktop environment,
> though.

Let's put this into perspective: while this has been one of the
theoretical motivators of the XEmacs package system, the ratio of
people who don't use the "Sumo tarball" of everything is rather small.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: CVS is the `released version'

[Tom Tromey]

>>>>> "David" == David Kastrup <dak@gnu.org> writes:

David> The XEmacs package system basically consists of several pieces of
David> policy: a package layout which packages have to obey, a central
David> package repository where packages are checked in via CVS and built,
David> servers populated from this repository and mirrored.

FWIW, package.el does require a specific layout of the package.  This
could be changed -- package.el is reasonably small -- but so far I
didn't see a need.  Essentially it requires everything (.el files, the
info files and also a dir file) in the top level.  It also mandates a
couple file names, the main one being the .el file that holds the
"define-package" call.

David> XEmacs policies, however, prohibit the distribution of packages not
David> built with the XEmacs-specific build tools.

package.el by contrast does not have a build tool :-)

David> The problem is that there are not that many great things around that
David> are not already integrated into Emacs.

I respectfully disagree.  I'm regularly using a couple great packages
that for whatever reason, AIUI, will never be integrated into Emacs
(VM and BBDB).  There's also things like muse, planner, emms, RLX,
dvc, etc -- some of which may be integrated someday, but meanwhile it
would be nice to have a simpler way to install them.  Finally there's
the issue of Emacs' release cycle -- frequently it would be nice to
update an Emacs package like Gnus to some intermediate release.

David> With all that policing, the administrative burden is actually more
David> than getting some Lisp file accepted into the Emacs core tree.

package.el is tied to ELPA, the Emacs Lisp Package Archive.  My plan
here is to turn this into a project hosted on savannah or the like,
run it as a free software project is run, and then give the major
package maintainers login access.  IOW, you could update the AUCTeX
packages yourself.

For smaller packages, uploading is trivial if the package meets the
packaging guidelines.  I have it bound to a key in Gnus :-).  This
sort of thing can comfortably be done by anyone with ELPA admin
access.

Tom

Re: CVS is the `released version'

[Richard Stallman]

       I don't see how any code installed in Emacs could save you the need
       for that.

    In my quick test of package.el, I was able to install and run a
    package in 1/10th the time it would have taken to find, download and
    install it manually.

Can you explain why this is so?  What are the jobs that you need
to do without package.el, which package.el avoids?

       Since just loading the files is not supposed to change Emacs
       functionality, I think the need for this cannot be avoided.

    Having the package system install the file and setup autoloads in
    .emacs will not itself change emacs functionality, but will save the
    user a tremendous amount of tedious work.

I can see how putting the autoloads in a suitable place would be a
savings.

That is something that could be done by a function to install certain
Lisp code, which does not need that Lisp code to be a "package".

Re: CVS is the `released version'

[Tom Tromey]

>>>>> "RMS" == Richard Stallman <rms@gnu.org> writes:

RMS> Can you explain why this is so?  What are the jobs that you need
RMS> to do without package.el, which package.el avoids?

package.el will install the dependencies of a package you are
installing.  It extracts autoloads and byte-compiles the lisp.  When
the package is activated, it sets up the load-path, the info path, and
evals the autoloads.  It also lets you install newer versions of
existing packages, and is smart about only activating the most recent.

In the future it will let you delete packages as well (a simple
operation, but I didn't want to include it in early releases).

RMS> That is something that could be done by a function to install certain
RMS> Lisp code, which does not need that Lisp code to be a "package".

First, please note that a "package" in most cases is really just a
single .el file.  More complicated things do need to be bundled (e.g.,
ELPA provides an old version of "url" for Emacs 21 users), but this
bundling is just a tar file (whose top-level directory has a certain
name) and a single extra file (e.g., "url-pkg.el", contained in the
tar).  Even for the "big program" case there is very little
administrative overhead here -- just a single call to
(define-package).

package.el has the code to install a lisp file.  This is not foolproof
because, in my experience, most Emacs Lisp files need a tweak or two
before they can be said to follow the comment guidelines.  The fixes
are generally trivial.

I thought I would use the installation code more, but it turns out to
be just as easy to upload a file to ELPA and then share it with
everybody.  And also the package-menu mode is fun to use :-)

Tom

Re: CVS is the `released version'

[Ryan Yeske]

       In my quick test of package.el, I was able to install and run a
       package in 1/10th the time it would have taken to find, download and
       install it manually.

   Can you explain why this is so?  What are the jobs that you need
   to do without package.el, which package.el avoids?

I installed package.el.  Then I ran package-list-packages, was
presented with a list of available packages in a buffer.  I hit RET on
wtf, which is a package that looks up acronyms.  package.el downloaded
the code, and installed and evaluated autoloads.  I was then able to
simply do M-x wtf to play with the new code.

Had I done this manually, I would have had to locate via a web search
where to ftp wtf.tar.gz (or whatever form it would be in), download it
via ftp or http, save it to my personal elisp directory, untar it, and
read the INSTALL file, or the commentary in the elisp file to find out
what autoloads to add to my .emacs file.  I would never have bothered
trying out wtf.el.

       Having the package system install the file and setup autoloads in
       .emacs will not itself change emacs functionality, but will save the
       user a tremendous amount of tedious work.

   I can see how putting the autoloads in a suitable place would be a
   savings.

   That is something that could be done by a function to install certain
   Lisp code, which does not need that Lisp code to be a "package".

Perhaps we are talking about different definitions of package.  I am
not referring to package system in elisp, in the same sense that
common lisp has a package system, but simply a system for automating
the routine retrieval and installation steps for making emacs
extensions available.

Re: CVS is the `released version'

[Mike Mattie]

[-- Attachment #1.1: Type: text/plain, Size: 2513 bytes --]

On Mon, 14 May 2007 04:09:00 -0400
Richard Stallman <rms@gnu.org> wrote:

>        I don't see how any code installed in Emacs could save you the
> need for that.
> 

I have looked often for an "official" repository, simply because I do not want to
install a third party component that may be unavailable later if the code/author
disappears.

There is alot of emacs code that isn't distributed AFAIK with emacs with
significant user bases. SLIME , CEDET, EDB, JDEE. SLIME in particular is
an amazing piece of software.

Along with the extremely high quality packages , a repository with a lower
bar than emacs cvs would encourage people to take the plunge into publishing
their elisp hacks to the world. A softer soil for new code/developers.

I don't think it takes elisp code to manage an archive of that sort. Existing
package managers such as paludis could be used to manage a elisp tree, and
a simple modification to the .emacs file could recursively traverse and load
the top-level .elc? files it finds. Then you have a repository loader instead
of a complete repository system which is a enormous re-invention of the wheel.

paludis supports multiple repositories, periodic syncs for versioned repos,
and a host of other features. There are several package managers out there
with fairly light setup.

Even if a package repository is not created I think a search engine for elisp
code would be nice. It could even be a simple google-shortcut from the emacs page.
It would serve to link together the current emacs universe which is scattered
to the winds outside of emacs cvs. (Usually some university student's home-page
or some such thing)

Anyways most linux users at least are served by a distribution which has all
the functionality that has been discussed above. It's where I get my emacs-cvs,
foo-cvs, foo-wherever with full dependency information.

If this sort of infrastructure is set-up by emacs it's to bring the now ancient
revolution of the package manager to windows IMHO (where emacs works well but
feels stripped without hours of tracking down the far-flung components needed
to get the functionality of a linux distro installed emacs).

> 
> That is something that could be done by a function to install certain
> Lisp code, which does not need that Lisp code to be a "package".
> 
> 
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-devel

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: CVS is the `released version'

[Tom Tromey]

>>>>> "RMS" == Richard Stallman <rms@gnu.org> writes:

>>     Tom Tromey posted a simple implementation of a package system to
>>     emacs.sources recently. It works fairly well, so the time is already
>>     invested.

RMS> I wish that were true, but most of the work of installing a package
RMS> system is making everything _use_ it.

Actually this package manager was designed with the goal of making it
very easy to support.  If package.el were included in Emacs it would
require listing some version information for packages included in
Emacs, and invoking (package-initialize) during startup.  So I think
this could be supported without much difficulty in Emacs itself.

>>     Compared with systems like Eclipse, installing an emacs package
>>     consists of some fairly boring obviously automatable steps. (like
>>     hunting for the package,

RMS> I don't see how any code installed in Emacs could save you the need
RMS> for that.

package.el is attached to a web site, ELPA, where package updates are
uploaded.  The idea here is twofold.  First, many packages are
released between Emacs releases; package.el makes it simple to update
to these releases and use them.  Second, not every useful Emacs Lisp
package out there is going to be included in Emacs.  We've seen over
the years that having a separate repository is in fact very useful to
Emacs users.

Another thing package.el provides is simple installation.  Packages
are downloaded (including their dependencies, if any) and installed
for you, autoloads are extracted, the package is byte-compiled, and
when Emacs starts up,the packages are "activated" (meaning the
autoloads are evalled).  Users don't have to modify their .emacs for
updates to load-path, the Info path, or a list of autoloads.

There aren't many packages in ELPA yet.  However my experience has
been that packages consisting of a single .el file (the most common
kind) are very easy to fix up for inclusion.  That's because
package.el can usually extract the information it needs for files
following the already existing Emacs commenting guidelines.

Currently ELPA is hosted on my web site but I plan to turn it into a
project on savannah or the like.

Tom

Re: CVS is the `released version'

[Thien-Thi Nguyen]

() Tom Tromey <tromey@redhat.com>
() Sun, 13 May 2007 18:17:15 -0700

   packages consisting of a single .el file (the most common
   kind) are very easy to fix up for inclusion.  That's because
   package.el can usually extract the information it needs for files
   following the already existing Emacs commenting guidelines.

does "very easy" include "without modification"?  that would be great.
someone else mentioned that xemacs' package system imposes policy that
ends up not being followed.  what plans would you have to make
package.el operate completely heuristically (possibly w/ human
intervention to fix glitches)?

i think the long-term merit of package.el will not be what it can do
given assistence (compliance to policy), but what it can do w/o.

thi

Re: CVS is the `released version'

[David Kastrup]

Thien-Thi Nguyen <ttn@gnuvola.org> writes:

> () Tom Tromey <tromey@redhat.com>
> () Sun, 13 May 2007 18:17:15 -0700
>
>    packages consisting of a single .el file (the most common
>    kind) are very easy to fix up for inclusion.  That's because
>    package.el can usually extract the information it needs for files
>    following the already existing Emacs commenting guidelines.
>
> does "very easy" include "without modification"?  that would be great.
> someone else mentioned that xemacs' package system imposes policy that
> ends up not being followed.

That would likely have been me.  The problem is rather that the
policies _end_ up being followed, and that means that packages like
AUCTeX (which are built upstream with a much more flexible build
process catering for more than XEmacs alone) are not permitted into
the XEmacs repository, meaning that somebody has to split the finished
package into its parts and write recipes that make the XEmacs package
builder (which exists only in XEmacs CVS) reassemble exactly the same
package with which one started.

Only then may it be distributed.  So the policies _are_ being
followed, with the result that XEmacs distributes only packages that
are severely outdated, with severe bugs that have been fixed for
yours, for the sake of "quality control".  If it looks like an XEmacs
package, behaves like an XEmacs package, smells like an XEmacs
package, it is still not distributed in XEmacs' central package
repository if it has not been assembled in the XEmacs CVS.

We don't want to go the same path of centralized package
repositories.  Really.

-- 
David Kastrup

Re: CVS is the `released version'

[Tom Tromey]

>>>>> ">" == Thien-Thi Nguyen <ttn@gnuvola.org> writes:

Tom>    packages consisting of a single .el file (the most common
Tom>    kind) are very easy to fix up for inclusion.  That's because
Tom>    package.el can usually extract the information it needs for files
Tom>    following the already existing Emacs commenting guidelines.

>> does "very easy" include "without modification"?  that would be great.
>> someone else mentioned that xemacs' package system imposes policy that
>> ends up not being followed.  what plans would you have to make
>> package.el operate completely heuristically (possibly w/ human
>> intervention to fix glitches)?

If you have a self-contained .el file that follows the Emacs
commenting guidelines, then it can be uploaded and distributed without
modifications.

Most modifications I've had to make in practice have been along the
lines of fixing the formatting of the "foo.el ends here" comment, or
adding a "Version:" header.

Tom

Re: CVS is the `released version'

[Stefan Monnier]

> Most modifications I've had to make in practice have been along the
> lines of fixing the formatting of the "foo.el ends here" comment, or
> adding a "Version:" header.

AFAIK, even those requirements could be dropped.
After all, most single-file packages are "self-contained" and no other
package depends on it, so version-information for dependency tracking is
really a luxury more than a need for those.


        Stefan

Re: CVS is the `released version'

[David Kastrup]

Tom Tromey <tromey@redhat.com> writes:

> package.el is attached to a web site, ELPA, where package updates
> are uploaded.  The idea here is twofold.

The central repository (and the necessary policies for maintaining it,
and the requirement to find intermediaries) is what I find works
absolutely worst with the XEmacs package system.  It is the main
culprit for XEmacs distributing outdated packages.

Once one has a central repository, there is no significant advantage
over not having packages but instead putting everything inside of
Emacs.

> First, many packages are released between Emacs releases; package.el
> makes it simple to update to these releases and use them.  Second,
> not every useful Emacs Lisp package out there is going to be
> included in Emacs.  We've seen over the years that having a separate
> repository is in fact very useful to Emacs users.

Who saw that?

> Another thing package.el provides is simple installation.  Packages
> are downloaded (including their dependencies, if any) and installed
> for you, autoloads are extracted, the package is byte-compiled, and
> when Emacs starts up,the packages are "activated" (meaning the
> autoloads are evalled).  Users don't have to modify their .emacs for
> updates to load-path, the Info path, or a list of autoloads.

They don't have for packages that are included in Emacs, anyway.

-- 
David Kastrup

Re: CVS is the `released version'

[joakim]

I think we have different experiences, which maybe accounts for our
diffierent views on package systems.

I havent used XEmacs much at all, and have no experience with its
package system. What David describes about it sounds like its mostly a
hassle, so I agree we dont want a package system like that.

It seems the XEmacs package system is mostly geared towards
modularizing emacs itself. I wouldnt need that for my emacs usage
patterns. If emacs was 1TB big, I would still download and use it, and
the size of a typical emacs install is not particularily bothersome
compared with most other software packages out there.

The particular need I feel Toms ELPA forfills is exploring emacs
packages that are not already in emacs core. Having a central
repository would also make it easier for such packages to eventualy be
accepted in emacs core.

Take for example two such valuable packages as CEDET and ECB. Both are
candidates for emacs inclusion, but have existed as separate packages
for years, and it will probably be years still before they are
included in a released emacs. These packages deserve a much larger
user-base, which they could have had with a package system such as ELPA.

If the only emacs that was available to me was the released emacs and
the packages that followed with it, I would very likely not be an
emacs user. 

David Kastrup <dak@gnu.org> writes:


> Tom Tromey <tromey@redhat.com> writes:
>
>> package.el is attached to a web site, ELPA, where package updates
>> are uploaded.  The idea here is twofold.
>
> The central repository (and the necessary policies for maintaining it,
> and the requirement to find intermediaries) is what I find works
> absolutely worst with the XEmacs package system.  It is the main
> culprit for XEmacs distributing outdated packages.
>
> Once one has a central repository, there is no significant advantage
> over not having packages but instead putting everything inside of
> Emacs.
>
>> First, many packages are released between Emacs releases; package.el
>> makes it simple to update to these releases and use them.  Second,
>> not every useful Emacs Lisp package out there is going to be
>> included in Emacs.  We've seen over the years that having a separate
>> repository is in fact very useful to Emacs users.
>
> Who saw that?
>
>> Another thing package.el provides is simple installation.  Packages
>> are downloaded (including their dependencies, if any) and installed
>> for you, autoloads are extracted, the package is byte-compiled, and
>> when Emacs starts up,the packages are "activated" (meaning the
>> autoloads are evalled).  Users don't have to modify their .emacs for
>> updates to load-path, the Info path, or a list of autoloads.
>
> They don't have for packages that are included in Emacs, anyway.
>
> -- 
> David Kastrup

-- 
Joakim Verona

Re: CVS is the `released version'

[Tom Tromey]

>>>>> "David" == David Kastrup <dak@gnu.org> writes:

David> Once one has a central repository, there is no significant advantage
David> over not having packages but instead putting everything inside of
David> Emacs.

I don't agree.

The biggest benefit I see is that packages can be updated on the
package maintainer's schedule.  Emacs, on the other hand, is updated
on the Emacs maintainers' schedule.

There's also the fact that there are useful Emacs packages which will
never be included in Emacs.

>> First, many packages are released between Emacs releases; package.el
>> makes it simple to update to these releases and use them.  Second,
>> not every useful Emacs Lisp package out there is going to be
>> included in Emacs.  We've seen over the years that having a separate
>> repository is in fact very useful to Emacs users.

David> Who saw that?

Everybody who ever used the Ohio State Elisp Archive, ELL, or uploaded
or downloaded code from the Emacs Wiki.

Tom

Re: CVS is the `released version'

[Ryan Yeske]

   David> Once one has a central repository, there is no significant advantage
   David> over not having packages but instead putting everything inside of
   David> Emacs.

   I don't agree.

   The biggest benefit I see is that packages can be updated on the
   package maintainer's schedule.  Emacs, on the other hand, is updated
   on the Emacs maintainers' schedule.

   There's also the fact that there are useful Emacs packages which will
   never be included in Emacs.

There is also no reason that we couldn't extend package.el to read
from multiple repositories, much like Debian's sources.list file, for
those familiar with that system.

That way, I could maintain an up-to-date package repository for my
personal projects if people wanted the bleeding edge versions that
weren't yet in the 'central' repository.  If people wanted access to
these package versions, they would simple add 'ftp://yeske.ca/elpa' to
their list of package-repositories.

Ryan

Re: CVS is the `released version'

[Eli Zaretskii]

> Date: Mon, 14 May 2007 08:10:43 -0700
> From: Tom Tromey <tromey@redhat.com>
> Cc: Tom Tromey <tromey@redhat.com>, rms@gnu.org, joakim@verona.se,
> 	emacs-devel@gnu.org
> 
> The biggest benefit I see is that packages can be updated on the
> package maintainer's schedule.  Emacs, on the other hand, is updated
> on the Emacs maintainers' schedule.

There are problems with this that no package system can ever solve: a
package that is released asynchronously from Emacs runs a high risk to
become broken by changes in Emacs.  Packages that are released
together with Emacs are generally coherent with the Emacs core, by
contrast.

As long as this is a real problem (and I personally don't see how it
can be solved, given the high rate of changes in core code), this
``biggest benefit'' is actually a myth, IMHO.

Re: CVS is the `released version'

[Tom Tromey]

>>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:

Eli> There are problems with this that no package system can ever solve: a
Eli> package that is released asynchronously from Emacs runs a high risk to
Eli> become broken by changes in Emacs.  Packages that are released
Eli> together with Emacs are generally coherent with the Emacs core, by
Eli> contrast.

Yes, that is true for some subset of packages.  But, it is by no means
universally true.

And, package.el makes an attempt to solve a related problem
experienced by users (me, at the very least): when an external package
is included in Emacs, package.el knows to disable the privately
installed copy in favor of the newer version included in Emacs.

Eli> As long as this is a real problem (and I personally don't see how it
Eli> can be solved, given the high rate of changes in core code), this
Eli> ``biggest benefit'' is actually a myth, IMHO.

I think you are drawing an overly general conclusion here.  A package
manager does not have to be perfect and solve every conceivable case
in order to be better than the status quo.  It merely has to provide
some tangible benefit to users.  Not solving every case does not
entirely eliminate the benefits of this application.

And, anyway, when a new Emacs is released, package maintainers can
update their packages.

Tom

Re: CVS is the `released version'

[Ryan Yeske]

   There are problems with this that no package system can ever solve: a
   package that is released asynchronously from Emacs runs a high risk to
   become broken by changes in Emacs.  Packages that are released
   together with Emacs are generally coherent with the Emacs core, by
   contrast.

   As long as this is a real problem (and I personally don't see how it
   can be solved, given the high rate of changes in core code), this
   ``biggest benefit'' is actually a myth, IMHO.

I have run emacs-w3m and bbdb across different emacs versions without
problems.  If changes in emacs do result in breakage in a package,
then updating installed packages can be done much more easily than
manually downloading and reinstalling updated packages.

Of course packages that are released together with emacs may not have
this problem, but we are talking about making a convenient way to
deliver third party packages to users.  Perhaps then, this is actually
outside the scope of emacs-devel@, as a package system like the one we
have been discussing doesn't need even need to be a part of emacs.

Ryan

Re: CVS is the `released version'

[Stefan Monnier]

>> The biggest benefit I see is that packages can be updated on the
>> package maintainer's schedule.  Emacs, on the other hand, is updated
>> on the Emacs maintainers' schedule.

Pleae, let's not link the issue of including a package-installer (such as
package.el) with the issue of which packages to (un)bundle.
These are completely separate questions.

package.el is useful to deal with non-bundled packages: there are many of
those and they're not about to be all bundled.


        Stefan

Re: CVS is the `released version'

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> The biggest benefit I see is that packages can be updated on the
>>> package maintainer's schedule.  Emacs, on the other hand, is updated
>>> on the Emacs maintainers' schedule.
>
> Pleae, let's not link the issue of including a package-installer (such as
> package.el) with the issue of which packages to (un)bundle.
> These are completely separate questions.
>
> package.el is useful to deal with non-bundled packages: there are
> many of those and they're not about to be all bundled.

I would think that if we could be able to say "if you have organized
your Lisp source files in such&such a way with this&that information
in the following format in its head, then using the command
M-x package-pull-into-current RET filename.el RET
will install the file and its associated files into your currently used
Emacs.  Using the command
M-x package-pull-into-source RET filename.el RET
will make it a part of your Emacs source tree (which you can then
either compile or commit).  And
M-x package-update RET filename.el RET
will look up any dedicated servers declared in the comments from
filename.el and will replace it (and its associated files) by a new
version which you can then either pull into current or pull into
source.

That would be a good feature/thing/whatever, and it could be made to
work with everything included in Emacs.  It could even ask whether you
want to pull from some package server, the last release from the
declared upstream, or a vc version from.

Creating a bunch of easy to follow conventions for this kind of
functionality, and updating source files to follow them by and by
would be a fine idea, I think.

But everything prescribing rigid procedures, policies, servers etc to
satisfy (like the XEmacs package system and its associated policies)
is asking for organized stagnation.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: CVS is the `released version'

[Stefan Monnier]

>>>> The biggest benefit I see is that packages can be updated on the
>>>> package maintainer's schedule.  Emacs, on the other hand, is updated
>>>> on the Emacs maintainers' schedule.
>> 
>> Pleae, let's not link the issue of including a package-installer (such as
>> package.el) with the issue of which packages to (un)bundle.
>> These are completely separate questions.
>> 
>> package.el is useful to deal with non-bundled packages: there are
>> many of those and they're not about to be all bundled.

> I would think that if we could be able to say "if you have organized
> your Lisp source files in such&such a way with this&that information
> in the following format in its head, then using the command
> M-x package-pull-into-current RET filename.el RET
> will install the file and its associated files into your currently used
> Emacs.  Using the command
> M-x package-pull-into-source RET filename.el RET
> will make it a part of your Emacs source tree (which you can then
> either compile or commit).  And
> M-x package-update RET filename.el RET
> will look up any dedicated servers declared in the comments from
> filename.el and will replace it (and its associated files) by a new
> version which you can then either pull into current or pull into
> source.

I don't see any relation with what I said.


        Stefan

Re: CVS is the `released version'

[thorne]

Tom Tromey <tromey@redhat.com> writes:

> Everybody who ever used the Ohio State Elisp Archive, ELL, or uploaded
> or downloaded code from the Emacs Wiki.

Just a couple of thoughts from an end-user.  Safe to ignore.

It seems like the basic logic in package.el could be useful for other
related things.  For instance, what's to stop one from writing a
little code to use the url package to grab something from, say, the
Google Usenet archives of gnu.emacs.sources, try to strip headers and
`this is my first post to g.e.sources' blah blah and then feed it to
package.el?  Or a function like
`gnus-install-lisp-package-from-message'?  Same goes for source on the
EmacsWiki.  The function could just give a graceful error message if
it couldn't extract the lisp, or if it was malformed as a package.

Assuming the source had version info it could work just as well as
something downloaded from an official repository.

As for version conflicts with new releases of Emacs, isn't that
something users expect to happen sometimes when they try to install
anything that didn't come with their base Emacs?

-- 
þ    theron tlåx    þ
(compose-mail (concat "thorne@" (rot13 "gvzoeny") ".net"))

Re: CVS is the `released version'

[Richard Stallman]

    package.el is attached to a web site, ELPA, where package updates are
    uploaded.

In that case, I think the real proposal is not "add a package system
to Emacs" but rather "set up a standard site for Emacs add-ons".

If the add-ons are put in such a web site, finding and installing them
would be much easier.  Maybe it is worth doing that, though calling it
a "package system" seems like hype.

But there are two important non-technical problems with this approach.

1. It could reduce the incentive for people to assign copyright on
their code.

2. It would mean that Emacs refers people very strongly to a site that
isn't run by the GNU Project.  I don't know what their policies are.
But even if they are good, now, we have no way to assure that remains
so.

These problems would be eliminated if we put the package repository on
gnu.org and limit it to packages that are copyright FSF.

In other words, I can see that installing packages in a separate
repository and releasing them there, but I don't want this to
alter the legal and publicity arrangements that we would have
made for including them in Emacs.

      Packages
    are downloaded (including their dependencies, if any) and installed
    for you, autoloads are extracted, the package is byte-compiled, and
    when Emacs starts up,the packages are "activated" (meaning the
    autoloads are evalled).

It sounds convenient.  As long as it doesn't require a lot of change
in how you write the Lisp programs, I have nothing against this.

      It also mandates a
    couple file names, the main one being the .el file that holds the
    "define-package" call.

Something like a "define-package" call is one of the things that makes
me dislike package systems.  Can we avoid this?  Why is it needed?

Re: CVS is the `released version'

[Tom Tromey]

>>>>> "rms" == Richard Stallman <rms@gnu.org> writes:

rms> Maybe it is worth doing that, though calling it a "package
rms> system" seems like hype.

Perhaps we have different ideas about what this means.  My use comes
from the distro world, where it basically refers to the combination of
"binary" downloads and dependency tracking.  I'm not a real lisp
programmer but I gather this has some other meaning in the lisp
world...?

rms> 1. It could reduce the incentive for people to assign copyright
rms> on their code.

Yeah, this is definitely to be preferred.  I'm not comfortable
requiring it, though, because there are very useful Emacs Lisp
packages which, AIUI, will never be assigned to the FSF.

rms> 2. It would mean that Emacs refers people very strongly to a site that
rms> isn't run by the GNU Project.  I don't know what their policies are.
rms> But even if they are good, now, we have no way to assure that remains
rms> so.

Currently there is no "they", just me :).  My current policy is that
ELPA accepts anything that is free software.

Of course we could have an official GNU ELPA and then also change
package.el to support multiple repository URLs, so that users could
point to some non-FSF repository.

I wouldn't have a problem asking people to assign their code first,
and only uploading to the other repository if they say no.

>       It also mandates a
>     couple file names, the main one being the .el file that holds the
>     "define-package" call.

rms> Something like a "define-package" call is one of the things that makes
rms> me dislike package systems.  Can we avoid this?  Why is it needed?

It is only needed for multi-file packages.  Essentially package.el
needs 3 pieces of information about a package: its name, its version
number, and its requirements.  For a single-file package these are
extracted from comments; package.el defines a new comment header
("Package-Requires") for requirements, but so far I think this is
unused.

For a multi-file package the problem is just knowing where to look to
get this information.  It seemed simplest to have the package
maintainer provide it in a well-known place.

For a single-file package the quux-pkg.el file is generated by
package.el at install time.

Tom

Re: CVS is the `released version'

[Richard Stallman]

    rms> 1. It could reduce the incentive for people to assign copyright
    rms> on their code.

    Yeah, this is definitely to be preferred.  I'm not comfortable
    requiring it, though, because there are very useful Emacs Lisp
    packages which, AIUI, will never be assigned to the FSF.

I'm not comfortable with having Emacs automatically install and load
anything that isn't copyright FSF.  So if we do install a feature like
this, it will use only one repository, on gnu.org.

Re: CVS is the `released version'

[Tom Tromey]

>>>>> "rms" == Richard Stallman <rms@gnu.org> writes:

rms> I'm not comfortable with having Emacs automatically install and load
rms> anything that isn't copyright FSF.  So if we do install a feature like
rms> this, it will use only one repository, on gnu.org.

How about if I change things so that package.el looks at a list of
repositories, which by default only includes the FSF-owned site?
That way people can set up additional repositories as well.
This isn't quite as friendly for users but is, IMO, workable.

Tom

Re: CVS is the `released version'

[Richard Stallman]

    How about if I change things so that package.el looks at a list of
    repositories, which by default only includes the FSF-owned site?

This might tempt redistributors (such as GNU/Linux distros) to add
other repositories.  I don't want to ask for trouble.

Re: CVS is the `released version'

[Tom Tromey]

>>>>> "rms" == Richard Stallman <rms@gnu.org> writes:

>     How about if I change things so that package.el looks at a list of
>     repositories, which by default only includes the FSF-owned site?

rms> This might tempt redistributors (such as GNU/Linux distros) to add
rms> other repositories.  I don't want to ask for trouble.

Unfortunately this does not align very well with my goals in writing
package.el.  My goal is to make it much simpler for Emacs users to
download and install the many useful un-integrated Emacs packages that
are out there.  And, in my view, this has to include the 3rd party,
unassigned code -- there's a wealth of this on ELL and the Emacs Wiki,
and its existence, far from hurting Emacs in some way, is actually a
vital part of the thriving Emacs community.

So I think we've reached an impasse.  I suppose package.el can
comfortably continue to live outside of Emacs itself.  With the auto
installer (and the coming code to update package.el itself) it is not
a big problem for interested users to install it.

Tom

Re: CVS is the `released version'

[David Kastrup]

Tom Tromey <tromey@redhat.com> writes:

>>>>>> "rms" == Richard Stallman <rms@gnu.org> writes:
>
>>     How about if I change things so that package.el looks at a list of
>>     repositories, which by default only includes the FSF-owned site?
>
> rms> This might tempt redistributors (such as GNU/Linux distros) to add
> rms> other repositories.  I don't want to ask for trouble.
>
> Unfortunately this does not align very well with my goals in writing
> package.el.  My goal is to make it much simpler for Emacs users to
> download and install the many useful un-integrated Emacs packages that
> are out there.  And, in my view, this has to include the 3rd party,
> unassigned code -- there's a wealth of this on ELL and the Emacs Wiki,
> and its existence, far from hurting Emacs in some way, is actually a
> vital part of the thriving Emacs community.

I more or less agree.  The first letter of Emacs stands for
"Extensible", and where is the point in extending if sharing is made
complicated?  This certainly holds for those things that are not of
general interest, but even those that end up in CVS proper take time
and work to integrate into the tree, time that could be better spent.
If it was usually a single command to grab a package into the tree,
that would save time and work.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: CVS is the `released version'

[Richard Stallman]

It seems that part of your motivation for wanting a package system is
to move Emacs development in a direction that weakens the FSF's
ability to develop Emacs as an FSF-copyrighted package.
This confirms my concern about the downside.

Re: CVS is the `released version'

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

> It seems that part of your motivation for wanting a package system is
> to move Emacs development in a direction that weakens the FSF's
> ability to develop Emacs as an FSF-copyrighted package.
> This confirms my concern about the downside.

I don't think this is a fair characterization.  The idea is not, as
far as I can tell, to reduce the motivation for contributing material
into Emacs' core.  It is to provide a mechanism to work with things
that have no real place in the Emacs core.

In addition, if done right, it could make it _easier_ to pull material
into Emacs' core: right now there are no hard rules for what a Emacs
package (a conglomerate of Lisp files, auxiliary files, documentation
and other stuff) should look like when wanting to get moved into
Emacs.  If there are some policies (like avoiding all absolute paths
or dependencies on the final system) made in connection with a package
system, it could mean that once a decision is made to make a package
an integral part of Emacs (instead of a separately distributed one),
this would be facilitated with a few commands and a commit.

Also, such a system could replace the vacuum that has called into
being the Debian Emacs packaging guidelines, which are not understood
by pretty much every Emacs and XEmacs developer, and not by all too
many Debian developers either.

I can't see how this would in any way diminuish the FSF's ability to
develop Emacs as an FSF-copyrighted package.  At the current point of
time, both pulling a (non-standardized) package into Emacs and
maintaining it externally is a source of pain.  A minimal package
system (which would probably consist more of structuring policies
rather than actual code implementing it) would reduce the pain on
either level.

-- 
David Kastrup

Re: CVS is the `released version'

[JD Smith]

On Mon, 21 May 2007 12:46:42 +0200, David Kastrup wrote:

> I can't see how this would in any way diminuish the FSF's ability to
> develop Emacs as an FSF-copyrighted package.  At the current point of
> time, both pulling a (non-standardized) package into Emacs and
> maintaining it externally is a source of pain. 

Isn't that the point?  That pain may be the motivation to assign
copyright and move a package into the mainline Emacs distribution.
Relieving it would lessen that motivation.  On the other hand, the
pain may simply discourage any development.  It's a fine line to walk.

At the very minimum, an integrated, easy to use capability to update
assigned, core Emacs packages between releases would be very welcome.

Re: CVS is the `released version'

[David Kastrup]

JD Smith <jdsmith@as.arizona.edu> writes:

> On Mon, 21 May 2007 12:46:42 +0200, David Kastrup wrote:
>
>> I can't see how this would in any way diminuish the FSF's ability to
>> develop Emacs as an FSF-copyrighted package.  At the current point of
>> time, both pulling a (non-standardized) package into Emacs and
>> maintaining it externally is a source of pain. 
>
> Isn't that the point?  That pain may be the motivation to assign
> copyright and move a package into the mainline Emacs distribution.

Where is the point if this act is equally painful?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: CVS is the `released version'

[Chong Yidong]

JD Smith <jdsmith@as.arizona.edu> writes:

> On Mon, 21 May 2007 12:46:42 +0200, David Kastrup wrote:
>
>> I can't see how this would in any way diminuish the FSF's ability to
>> develop Emacs as an FSF-copyrighted package.  At the current point of
>> time, both pulling a (non-standardized) package into Emacs and
>> maintaining it externally is a source of pain. 
>
> Isn't that the point?  That pain may be the motivation to assign
> copyright and move a package into the mainline Emacs distribution.
> Relieving it would lessen that motivation.  On the other hand, the
> pain may simply discourage any development.  It's a fine line to walk.
>
> At the very minimum, an integrated, easy to use capability to update
> assigned, core Emacs packages between releases would be very welcome.

An analogy can be drawn to the Debian apt system.  By default, this
points to the Debian software repositories, but it is trivial to add
third-party repositories to obtain packages that are not included in
Debian for whatever reason (software patent encumbered codecs,
experimental packages, etc.)  The presence of this feature does not
detract from Debian's ability to develop the Debian system.  All
things being equal, users generally use the default Debian package
rather than an equivalent third-party package, if a Debian package
exists; this is simply because the Debian package is better integrated
into the Debian system (just as Lisp packages distributed with Emacs
are better integrated into the rest of Emacs); but it is good to offer
people a choice.

Re: CVS is the `released version'

[David Kastrup]

Chong Yidong <cyd@stupidchicken.com> writes:

> An analogy can be drawn to the Debian apt system.  By default, this
> points to the Debian software repositories, but it is trivial to add
> third-party repositories to obtain packages that are not included in
> Debian for whatever reason (software patent encumbered codecs,
> experimental packages, etc.)

But a Debian package can't carry within itself the notion of what
repositories to use for it.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: CVS is the `released version'

[Richard Stallman]

    An analogy can be drawn to the Debian apt system.

Debian doesn't need to get copyright assignments before packaging a
program; we do need them, before we distribute a program in Emacs.
That changes everything.

In addition, Debian normally expects to find its own maintainers
for its own version of the program.  We want the developer of
the Lisp program to keep maintaining it as part of Emacs.

That makes two ways in which we need or want the developer's continued
cooperation.

If we were to help the users and the Lisp program developers bypass
us, we would be creating unnecessary difficulties for our efforts.  It
would be a mistake.  Our goal is not simply to make the users as happy
as possible in the short term.

Re: CVS is the `released version'

[Ken Manheimer]

On 5/21/07, JD Smith <jdsmith@as.arizona.edu> wrote:

> At the very minimum, an integrated, easy to use capability to update
> assigned, core Emacs packages between releases would be very welcome.

i agree - i think this issue is very important.  from people's
responses in this thread, it's apparent that it's complicated by a few
concerns.  i think the discussion is getting muddied by intermixing of
the concerns, and it would be helpful to explicity distinguish and
address them.  my take:

(1) we are talking about enabling package developers and users to update
     the packages they use incrementally within a major emacs release,
(2) without burdening emacs maintainers with change management chaos,
     and
(3) without reducing the incentive for package developers to assign
     copyright to the fsf.

(1) is the purpose of the thing, and seems quite valuable to me.  it
would reduce the pressure for emacs major releases, or conversely,
reduce the impedence that delays in an emacs major release presents.
those of us that feel confident about the general polish of the CVS
head, and our ability to tackle problems when they creep in, have a
version of this by using an emacs checked out and built form the head.
 we get bug fixes quickly, and get to enjoy valuable features and
improvements as they arrive.

(3) copyright assignment incentives could be maintained by requiring
copyright assignment for inclusion of a package in the system.  this
may be severe, however - perhaps it would be enough to require
assignment for inclusion in the default collection, but enable
inclusion of alternate collections?  i think this is the gist of one
of the discussions that tom tromey and richard are having in this
thread.  whatever the choice, it seems like this can be kept as close
to the status quo as desired, and relaxed as much as willing, by
choice.

(2) is the tricky bit.  the situation would be simplest if the update
system is contrived to only allow the entire collection of packages to
be updated at as a whole.  this would mean that package committers
need worry only about interoperation with the current version of other
packages, not with the diversity available.  ("current" would be a
gradually moving target, but at least there would be only one target
at any moment.)  what this would amount to is a finer incremental
release mechanism for the lisp directory, as a whole.  this would be
very like someone following emacs development via the CVS head, with
the addition that the releases could be better controlled to ensure
coherence/integrity, rather than being wherever checkins happen to be.

the cygwin installer for the cygwin gnu/linux distribution presents an
example of another, more intricate mode, which i like.  (gentoo's
portage and debian's apt systems are (much) more elaborate versions of
this mode, the cygwin version has the advantage of a compact, concise
interface.)

in it, collections of package versions are offered together, and the
user has to specifically elect for exceptions from the standard (or
alternate) version collections.  by deliberately choosing the
exceptions, the user is aware that they're departing from the
programmed situation.  we could even have bug reporting mechanisms
note such departures, to at least have the deviance reported.

the question here is how much turbulence would be introduced by
allowing more frequent incremental release of the packages, and
further, more intricate combinations of package versions.  i think
both are worth considering.
-- 
ken
http://myriadicity.net

Re: CVS is the `released version'

[Lennart Borgman (gmail)]

Ken Manheimer wrote:

> (2) is the tricky bit.  the situation would be simplest if the update
> system is contrived to only allow the entire collection of packages to
> be updated at as a whole.  this would mean that package committers
> need worry only about interoperation with the current version of other
> packages, not with the diversity available.  ("current" would be a
> gradually moving target, but at least there would be only one target
> at any moment.)  what this would amount to is a finer incremental
> release mechanism for the lisp directory, as a whole.  this would be
> very like someone following emacs development via the CVS head, with
> the addition that the releases could be better controlled to ensure
> coherence/integrity, rather than being wherever checkins happen to be.


I think this touches the most important point of a package system. There 
must be something that can assure that the package to download fits on 
the users system. Otherwise a package system may create a disaster.

For more complicated packages the alternative is otherwise to download 
the whole package. And in my opinion a package system is propably of 
most value if it assists in installing complicated packages.

It is quite simple to follow instructions to install single elisp files. 
I am not sure that a package system is really needed there. In contrast 
it may be very frustrating for a user getting the files in a package out 
of sync. A good package system can be a very good help to avoid that the 
package parts get out of sync.

So please, do not add a package system that can only handle single files 
and not their interdependencies.

Re: CVS is the `released version'

[David Kastrup]

"Ken Manheimer" <ken.manheimer@gmail.com> writes:

> (3) copyright assignment incentives could be maintained by requiring
> copyright assignment for inclusion of a package in the system.  this
> may be severe, however - perhaps it would be enough to require
> assignment for inclusion in the default collection, but enable
> inclusion of alternate collections?  i think this is the gist of one
> of the discussions that tom tromey and richard are having in this
> thread.  whatever the choice, it seems like this can be kept as
> close to the status quo as desired, and relaxed as much as willing,
> by choice.

I don't know how often I will have to repeat that point: a central
repository requirement is something which is not going to work out
well.  Packages should be able to know where they originate by
themselves.

Anyway, to get a view of what XEmacs uses, here are the defaults for
the user <URL:http://www.xemacs.org/Documentation/packageGuide.html>,
and here for the package contributor:
<URL:http://calypso.tux.org/pipermail/xemacs-beta/2005-June/006129.html>.
The latter link illustrates (and defends) some of the problems
stemming from a central repository approach.

What is not mentioned in there is that the administrative hurdle
(become XEmacs developer with CVS access) for package maintainers is
exacerbated by non-trivial packages in CVS having a completely
different file layout and control files that are not present in the
finished package.

A copyright assignment requirement would probably be a similar hurdle
as the CVS access is, however, since there is no way that a third
party can do the copyright assignment (and third part CVS
maintainenance of a package is quite common for XEmacs packages), it
would at least not intrpduce a division of forces for those package
that make it into a central repository.

And we also want to avoid a _technical_ hurdle, namely the CVS
(=source, except in XEmacs terminology) form of a package having a
different structure from the final package, a structure that can't be
mapped onto the other without the help of scripts and files specific
to the package in question.

That's another place where we don't want to go if we can avoid it.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: CVS is the `released version'

[dhruva]

Hi,

On 5/26/07, David Kastrup <dak@gnu.org> wrote:
> I don't know how often I will have to repeat that point: a central
> repository requirement is something which is not going to work out
> well.  Packages should be able to know where they originate by
> themselves.

A quick thought:
Is it feasible/practical to have a keyword in the comment area of the
file "providing" the package with list of depedencies and their
locations? If the locations are not given, we could assume that it in
the same location where the main package is hosted OR is part of emacs
distro.

-dky

-- 
Dhruva Krishnamurthy
Contents reflect my personal views only!

Re: CVS is the `released version'

[Richard Stallman]

    Is it feasible/practical to have a keyword in the comment area of the
    file "providing" the package with list of depedencies and their
    locations? If the locations are not given, we could assume that it in
    the same location where the main package is hosted OR is part of emacs
    distro.

It should be just names, not locations.  I agree this should be easy.

Re: CVS is the `released version'

[dhruva]

Hi,

On 5/29/07, Richard Stallman <rms@gnu.org> wrote:
>     Is it feasible/practical to have a keyword in the comment area of the
>     file "providing" the package with list of depedencies and their
>     locations? If the locations are not given, we could assume that it in
>     the same location where the main package is hosted OR is part of emacs
>     distro.
>
> It should be just names, not locations.  I agree this should be easy.

I think names are almost there. If a package follows a rule/standard
of making all 'require' in the top level file (file that provides the
package), we just can search for them to get that list. The real
problem remains, where do I find them...

with best regards,
dhruva

-- 
Dhruva Krishnamurthy
Contents reflect my personal views only!

Re: CVS is the `released version'

[Stephen J. Turnbull]

dhruva writes:

 > I think names are almost there. If a package follows a rule/standard
 > of making all 'require' in the top level file (file that provides the
 > package), we just can search for them to get that list.

It's not that easy.  You also need to account for auto-autoloads (if
the package developer already has a particular package, he may not
notice the requirement), and macros and defsubsts (if the developer
always has these in his environment, then for a user, the package may
compile, but error at runtime (missing macro) or be very inefficient
(missing defsubst).

Of course these are generally not difficult to correct, but presumably
the goal is to catch them in advance!

Re: CVS is the `released version'

[Frank Schmitt]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

>  > I think names are almost there. If a package follows a rule/standard
>  > of making all 'require' in the top level file (file that provides the
>  > package), we just can search for them to get that list.
>
> It's not that easy.  You also need to account for auto-autoloads (if
> the package developer already has a particular package, he may not
> notice the requirement), and macros and defsubsts (if the developer
> always has these in his environment, then for a user, the package may
> compile, but error at runtime (missing macro) or be very inefficient
> (missing defsubst).
>
> Of course these are generally not difficult to correct, but presumably
> the goal is to catch them in advance!

Perhaps one could build a system like fedoras mock (A system for
building rpms in a special build environment. The build environment
includes only those packages which are available on all installations. It
then downloads and install all packages which are explicitly required by
the package to be build, tries to build it and bails if this fails due
to missing requires.)

-- 
Did you ever realize how much text fits in eighty columns? If you now consider
that a signature usually consists of up to four lines, this gives you enough
space to spread a tremendous amount of information with your messages. So seize
this opportunity and don't waste your signature with bullshit nobody will read.

Re: CVS is the `released version'

[Stephen J. Turnbull]

Frank Schmitt writes:

 > Perhaps one could build a system like fedoras mock

You're missing my point.  One can, but not until you know about all of
the requirements.  A couple of people tried for XEmacs, and got bogged
down in the details, so we don't have them.  That's one reason why
instead of computing dependencies we simply say "build in the tree".

I'm not saying it's impossible, just that it's probably more work than
it looks at first glance.

Re: CVS is the `released version'

[Frank Schmitt]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> Frank Schmitt writes:
>
>  > Perhaps one could build a system like fedoras mock
>
> You're missing my point.  One can, but not until you know about all of
> the requirements.  A couple of people tried for XEmacs, and got bogged
> down in the details, so we don't have them.  That's one reason why
> instead of computing dependencies we simply say "build in the tree".
>
> I'm not saying it's impossible, just that it's probably more work than
> it looks at first glance.

Hmm. You argued that the developer might not notice that his package
requires things which he, locally, has installed but which aren't
available by default. I presented the way Fedora handles the same
problem for rpm-Packages.

The developer says "dear build system, I think I in my package humba, I
only use package foo, bar and baz". The build system installs foo, bar
and baz in *a clean environment outside of the developers workspace*
(e.g. a fresh CVS checkout of Emacs), tries to build humba there and
reports success or failure.

Maybe I'm stilling missing your point, I just wanted to make sure you
don't miss mine ;-)

-- 
Did you ever realize how much text fits in eighty columns? If you now consider
that a signature usually consists of up to four lines, this gives you enough
space to spread a tremendous amount of information with your messages. So seize
this opportunity and don't waste your signature with bullshit nobody will read.

Re: CVS is the `released version'

[Stephen J. Turnbull]

Frank Schmitt writes:

 > The developer says "dear build system, I think I in my package humba, I
 > only use package foo, bar and baz". The build system installs foo, bar
 > and baz in *a clean environment outside of the developers workspace*
 > (e.g. a fresh CVS checkout of Emacs), tries to build humba there and
 > reports success or failure.

Oh, OK, that will work.  But that's equivalent to what XEmacs does.
It tends toward centralization because it's most efficient if done in
the context of a comprehensive list of packages, all available in a
single repository.

Re: CVS is the `released version'

[David Kastrup]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> Frank Schmitt writes:
>
>  > The developer says "dear build system, I think I in my package humba, I
>  > only use package foo, bar and baz". The build system installs foo, bar
>  > and baz in *a clean environment outside of the developers workspace*
>  > (e.g. a fresh CVS checkout of Emacs), tries to build humba there and
>  > reports success or failure.
>
> Oh, OK, that will work.  But that's equivalent to what XEmacs does.
> It tends toward centralization because it's most efficient if done in
> the context of a comprehensive list of packages, all available in a
> single repository.

In practice it might well be that several, probably most packages will
tend to be provided from few canonical repositories.  But making this
obligatory is not a good idea, I think.  On the other hand, if a
central repository would also keep a list of "for this package, look
there" rather than keeping possibly outdated packages, the dependency
resolution would get quite easier already without either requiring
lots of manual hunting, and with better chances of getting updates
from upstream even when they don't bother pushing them to repositories
all the time.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: CVS is the `released version'

[Richard Stallman]

I will not agree to a package system that I believe undermines our
chances of getting copyright assignments for Lisp code that we would
like to add to Emacs.

Re: CVS is the `released version'

[joakim]

Richard Stallman <rms@gnu.org> writes:

> I will not agree to a package system that I believe undermines our
> chances of getting copyright assignments for Lisp code that we would
> like to add to Emacs.

That is reasonable. IMHO the proposed packaging systems do not have
this negative property.

Heres why I believe this:

- If a package author doesnt want to sign papers, why would he ever do
it?

- For a package to be included in Emacs is an honor, and there is
really no other reason, that I can see, to try to get ones package
included.



-- 
Joakim Verona

Re: CVS is the `released version'

[Richard Stallman]

    - If a package author doesnt want to sign papers, why would he ever do
    it?

To get the program included in Emacs.

    - For a package to be included in Emacs is an honor, and there is
    really no other reason, that I can see, to try to get ones package
    included.

I think the main reason is the desire for all the Emacs users
to get the code easily.

Re: CVS is the `released version'

[Frank Schmitt]

Richard Stallman <rms@gnu.org> writes:

>     - For a package to be included in Emacs is an honor, and there is
>     really no other reason, that I can see, to try to get ones package
>     included.
>
> I think the main reason is the desire for all the Emacs users
> to get the code easily.

This would be true if there were yearly releases...

-- 
Did you ever realize how much text fits in eighty columns? If you now consider
that a signature usually consists of up to four lines, this gives you enough
space to spread a tremendous amount of information with your messages. So seize
this opportunity and don't waste your signature with bullshit nobody will read.

Re: CVS is the `released version'

[Richard Stallman]

     > The developer says "dear build system, I think I in my package humba, I
     > only use package foo, bar and baz". The build system installs foo, bar
     > and baz in *a clean environment outside of the developers workspace*
     > (e.g. a fresh CVS checkout of Emacs), tries to build humba there and
     > reports success or failure.

    Oh, OK, that will work.  But that's equivalent to what XEmacs does.
    It tends toward centralization because it's most efficient if done in
    the context of a comprehensive list of packages, all available in a
    single repository.

We don't need to think about anything so complex.
If the list of dependencies are wrong, it is a bug and
the package maintainer fixes it.

Re: CVS is the `released version'

[Frank Schmitt]

Richard Stallman <rms@gnu.org> writes:

>      > The developer says "dear build system, I think I in my package humba, I
>      > only use package foo, bar and baz". The build system installs foo, bar
>      > and baz in *a clean environment outside of the developers workspace*
>      > (e.g. a fresh CVS checkout of Emacs), tries to build humba there and
>      > reports success or failure.
>
>     Oh, OK, that will work.  But that's equivalent to what XEmacs does.
>     It tends toward centralization because it's most efficient if done in
>     the context of a comprehensive list of packages, all available in a
>     single repository.
>
> We don't need to think about anything so complex.
> If the list of dependencies are wrong, it is a bug and
> the package maintainer fixes it.

The issue is: When packages are made available on some kind of package
repository (here repository doesn't mean CVS repository but some kind of
source from which users can obtain software), there is normally no
beta cycle: The developer pushes it to the repository and the users get
it from there. What I was talking about is a kind of automatic quality
control which tries to prevent that broken packages reach the
repository.

-- 
Did you ever realize how much text fits in eighty columns? If you now consider
that a signature usually consists of up to four lines, this gives you enough
space to spread a tremendous amount of information with your messages. So seize
this opportunity and don't waste your signature with bullshit nobody will read.

Re: CVS is the `released version'

[Richard Stallman]

    What I was talking about is a kind of automatic quality
    control which tries to prevent that broken packages reach the
    repository.

That might be a good idea, but if you want to work on it, please try
to make it a separate and modular facility--not a necessary part of
a package system itself.

Re: CVS is the `released version'

[Richard Stallman]

    I think names are almost there. If a package follows a rule/standard
    of making all 'require' in the top level file (file that provides the
    package), we just can search for them to get that list. The real
    problem remains, where do I find them...

That isn't a problem at all.  This issue is part of the discussion
about a detail in a program whose main feature is that it finds
packages.

Re: CVS is the `released version'

[Tom Tromey]

A few belated responses to this thread, all in one message.
I'll try to lay out some of my thinking behind package.el.

Ken> (1) we are talking about enabling package developers and users to update
Ken>     the packages they use incrementally within a major emacs release,
Ken> (2) without burdening emacs maintainers with change management chaos,
Ken>     and

package.el came from a few ideas.  The obvious one was to replace the
ELL/Wiki/Ohio State Archive with something more machine-friendly (and
thus simpler to make user-friendly).  However I also wanted to be able
to install a package (e.g., ERC) that was later pulled into Emacs;
upgrade Emacs; and have my old, personal ERC install not be used any
more.  I've run into this situation any number of times in the past,
and with the long Emacs release cycle and the many packages that exist
now, it seemed a bit more important.

This second idea basically works.  It would work better with a bit of
assistance from Emacs -- say a way to auto-compute the default value
for `package-alist' at build time.

Ken> (3) without reducing the incentive for package developers to assign
Ken>     copyright to the fsf.

I don't know how to accomplish this to RMS' satisfaction.  But perhaps
some of the infrastructure from package.el can still end up in Emacs.

Ken> (2) is the tricky bit.  the situation would be simplest if the
Ken> update system is contrived to only allow the entire collection of
Ken> packages to be updated at as a whole.

There are some theoretical problems here but I was planning to address
them from the "active maintenance" point of view -- i.e., the ELPA
maintainers would simply ensure, somehow, that the archive is
internally consistent.  This is related to...

Lennart> I think this touches the most important point of a package
Lennart> system. There must be something that can assure that the
Lennart> package to download fits on the users system.

I didn't want to try to deal with this in its full hairiness, but
package.el at least solves part of the problem, namely by letting
packages require minimum versions of other packages (including the
special package "emacs").

Lennart> So please, do not add a package system that can only handle
Lennart> single files and not their interdependencies.

package.el handles both `single' and `tar' packages, and either type
can have dependencies.  Which is related to...

Dhruva> Is it feasible/practical to have a keyword in the comment area
Dhruva> of the file "providing" the package with list of depedencies
Dhruva> and their locations?

package.el doesn't deal with locations -- it assumes a single
location.  I am not a fan of the location-per-package approach,
because I think a lesson from ELL is that locations often die.
However, package.el does handle requirements, even for `single'
packages, by defining a new "Package-Requires" header comment.  E.g.,
a .el file that requires Emacs 22 could have:

    ;; Package-Requires: ((emacs "22.0"))

Offhand I don't think anything currently in ELPA does this.  But then,
I haven't put much effort into trying to upload the bigger things out
there.

Tom

Re: CVS is the `released version'

[Richard Stallman]

    I don't think this is a fair characterization.  The idea is not, as
    far as I can tell, to reduce the motivation for contributing material
    into Emacs' core.  It is to provide a mechanism to work with things
    that have no real place in the Emacs core.

When we all agree on which class a given package is in, there would
probably be no problem.  My concern is with the cases where there is
disagreement -- such as VM.

    In addition, if done right, it could make it _easier_ to pull material
    into Emacs' core: right now there are no hard rules for what a Emacs
    package (a conglomerate of Lisp files, auxiliary files, documentation
    and other stuff) should look like when wanting to get moved into
    Emacs.

Yes there are.  Look at the Tips appendix.  The guidelines are quite
thorough.  I don't see where having a package system could possibly
help.  (I don't think it would hurt, either.)

The main obstacle in getting new libraries into Emacs is that of
making them modular, making them follow the conventions of Emacs, 
and sometimes cleaning up the code.  I just don't see how a package
system with its own repository(s) would change anything.

Re: CVS is the `released version'

[Tom Tromey]

>>>>> "rms" == Richard Stallman <rms@gnu.org> writes:

rms> It seems that part of your motivation for wanting a package system is
rms> to move Emacs development in a direction that weakens the FSF's
rms> ability to develop Emacs as an FSF-copyrighted package.
rms> This confirms my concern about the downside.

I was a bit surprised, and I suppose a little hurt, to read this.
Please ask about my motives rather than try to infer what they might
be.

I don't want to weaken the FSF's ability to develop emacs as an
FSF-copyright package.  I think that would be a bad idea.

My real motivation is that I got tired of jumping through hoops to
download and try out Emacs extensions.  I thought it would be fun and
useful to try to solve this problem in a user-friendly way.

In my view package.el does not make Emacs worse in any way.  To the
extent that it enables unassigned work, it is simply reflecting the
actually existing state of affairs -- there are many Emacs packages
which, for whatever reason, are not FSF-assigned and that probably
will never be.

There's another way to address this 3rd party elisp problem: you could
do outreach to the authors and ask them to contribute to Emacs.  ELL
and the Emacs Wiki have a long list of potential contributors.

Tom

Re: CVS is the `released version' (ELL and the ohio lisp archive)

[Stephen Eglen]

Tom Tromey <tromey@redhat.com> writes:


> There's another way to address this 3rd party elisp problem: you could
> do outreach to the authors and ask them to contribute to Emacs.  ELL
> and the Emacs Wiki have a long list of potential contributors.

As an aside to this discussion -- I created the ELL (Emacs lisp list)
ELL in September 1998, mostly because I was saddened to see that the
ohio elisp archive had fell into disuse, and thought the ELL would be
a quick fix to list files until another repository came along.  Little
did I think it would exist for more than a year or so, let alone close
to nine years.  I don't track how much it is used, but I hope it is
still useful.

However, I'd much rather see the return of something like the old lisp
archive, and I think something that Tom is doing should be supported,
since it would seem to essentially resurrect the archive concept in
addition to being a package manager.  (I personally probably wouldn't
use it immediately as a package manager, but would appreciate just
being able to browse the archive for code, ideas, etc.)

If this system gets elisp code more visibility, then great, and I'd
hope that eventually, if there is enough demand for certain pacakages,
they could get into Emacs core.

Stephen

Re: CVS is the `released version'

[Richard Stallman]

    There's another way to address this 3rd party elisp problem: you could
    do outreach to the authors and ask them to contribute to Emacs.  ELL
    and the Emacs Wiki have a long list of potential contributors.

We do want to do this, especially now that we can start installing
extensions again.  But this is a big job.

Would people like to start choosing which extensions we would like to
install, and talking with their developers about (1) the appropriate
changes for installation and (2) the necessary legal papers?

New Extensions (was: Re: CVS is the `released version')

[Henrik Enberg]

Richard Stallman <rms@gnu.org> writes:
> Would people like to start choosing which extensions we would like to
> install, and talking with their developers about (1) the appropriate
> changes for installation and (2) the necessary legal papers?

Some kind of CSS mode.  Personally, I prefer Stefan's.

http://www.iro.umontreal.ca/~monnier/elisp/css-mode.el

-- 
If animal trapped call 410-844-6286

Re: CVS is the `released version'

[Richard Stallman]

    rms> It seems that part of your motivation for wanting a package system is
    rms> to move Emacs development in a direction that weakens the FSF's
    rms> ability to develop Emacs as an FSF-copyrighted package.
    rms> This confirms my concern about the downside.

    I was a bit surprised, and I suppose a little hurt, to read this.
    Please ask about my motives rather than try to infer what they might
    be.

I apologize -- I should not have spoken about motivation.
But it does seem that the goal you stated would entail
this result.

Re: CVS is the `released version'

[Robert J. Chassell]

    rms> This might tempt redistributors (such as GNU/Linux distros)
    rms> to add other repositories.  I don't want to ask for trouble.

        Unfortunately this does not align very well with my goals in
        writing package.el.  ... download and install ... the 3rd
        party, unassigned code ...

Since all software in the United States is copyrighted on creation,
whether or not a copy of that code is sent to the copyright office,
unless it is specifically said to be public domain, downloading and
installing "3rd party, unassigned code" may mean `illegally using
code'.  Most programs, of course, are never used illegally.  But a few
may be.  This can be awkward.

Doubtless, you are thinking of code that you or people you trust have
checked for legality, but not every American does.

-- 
    Robert J. Chassell                          GnuPG Key ID: 004B4AC8
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc

Re: CVS is the `released version'

[David Kastrup]

"Robert J. Chassell" <bob@rattlesnake.com> writes:

>     rms> This might tempt redistributors (such as GNU/Linux distros)
>     rms> to add other repositories.  I don't want to ask for trouble.
>
>         Unfortunately this does not align very well with my goals in
>         writing package.el.  ... download and install ... the 3rd
>         party, unassigned code ...
>
> Since all software in the United States is copyrighted on creation,
> whether or not a copy of that code is sent to the copyright office,
> unless it is specifically said to be public domain, downloading and
> installing "3rd party, unassigned code" may mean `illegally using
> code'.  Most programs, of course, are never used illegally.  But a few
> may be.  This can be awkward.
>
> Doubtless, you are thinking of code that you or people you trust have
> checked for legality, but not every American does.

That sounds like making the tool responsible for the crime.  We are
not talking about something akin to "gun control" but rather to
"kitchen knife control".  The legitimate uses are much too farspread
that it makes sense blaming the tool for it.

And there is in particular no sense in banning a tool when that does
nothing to change the relative difficulty between legitimate and
illegitimate applications.

Anyway, we are not out to doing the government's work in shooting the
users in the foot.  We are bound by the laws, but we need not
proactively support them.

-- 
David Kastrup

Re: CVS is the `released version'

[Stefan Monnier]

>         Unfortunately this does not align very well with my goals in
>         writing package.el.  ... download and install ... the 3rd
>         party, unassigned code ...

> Since all software in the United States is copyrighted on creation,
> whether or not a copy of that code is sent to the copyright office,
> unless it is specifically said to be public domain, downloading and
> installing "3rd party, unassigned code" may mean `illegally using
> code'.  Most programs, of course, are never used illegally.  But a few
> may be.  This can be awkward.

You're confused: unassigned, just means that the copyright is not assigned
to the FSF.  It may still be (and generally is) properly licensed under
the GPL.


        Stefan

Re: CVS is the `released version'

[jasonr]

Quoting "Robert J. Chassell" <bob@rattlesnake.com>:

> Since all software in the United States is copyrighted on creation,
> whether or not a copy of that code is sent to the copyright office,
> unless it is specifically said to be public domain, downloading and
> installing "3rd party, unassigned code" may mean `illegally using
> code'.  Most programs, of course, are never used illegally.  But a few
> may be.  This can be awkward.

As we are talking about emacs-lisp packages here, assuming the code to be Free
is quite reasonable.

Re: CVS is the `released version'

[Robert J. Chassell]

    > ... Most programs, of course, are never used illegally.  But a few
    > may be.  This can be awkward.

    You're confused: unassigned, just means that the copyright is not
    assigned to the FSF.  It may still be (and generally is) properly
    licensed under the GPL.

No, I am not talking about those that are properly licensed.  I am
talking about the one -- that is all that is needed -- that is
mis-copyrighted and is supported by an organization which decides to
litigate, has lots of money, and does not mind losing.

   > Since all software in the United States is copyrighted on
   > creation, ...

   That sounds like making the tool responsible for the crime. ... 

No, it has to do with various ways of fighting to reduce excessive
costs (including the time of people who are not lawyers thinking about
this) for baseless litigation in the US.

Thus, in a country that follows the international treaty, instead of a
programmer making improvements to package.el, he might spend his time
in court instead.

   As we are talking about emacs-lisp packages here, assuming the code
   to be Free is quite reasonable.

That is not true if there is someone willing to spend several millions
of dollars, does not mind the defenses, and likely losing ...

-- 
    Robert J. Chassell                          GnuPG Key ID: 004B4AC8
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc

Re: CVS is the `released version'

[Stefan Monnier]

>> ... Most programs, of course, are never used illegally.  But a few
>> may be.  This can be awkward.
>     You're confused: unassigned, just means that the copyright is not
>     assigned to the FSF.  It may still be (and generally is) properly
>     licensed under the GPL.
> No, I am not talking about those that are properly licensed.  I am
> talking about the one -- that is all that is needed -- that is
> mis-copyrighted and is supported by an organization which decides to
> litigate, has lots of money, and does not mind losing.

Then I have no idea what scenario you have in mind where package.el makes
any difference.

> That is not true if there is someone willing to spend several millions
> of dollars, does not mind the defenses, and likely losing ...

But in what way would packake.el make any difference?


        Stefan

Re: CVS is the `released version'

[Robert J. Chassell]

   Then I have no idea what scenario you have in mind where package.el makes
   any difference.

Suppose a program in the package repository has been placed there in
order to hurt?  Most people and their organizations are good, but not
all.

Bear in mind, a statement on the program that `this is licensed under
the GPL' does not count.

--
    Robert J. Chassell                          GnuPG Key ID: 004B4AC8
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc

Re: CVS is the `released version'

[David Kastrup]

"Robert J. Chassell" <bob@rattlesnake.com> writes:

>    Then I have no idea what scenario you have in mind where package.el makes
>    any difference.
>
> Suppose a program in the package repository has been placed there in
> order to hurt?

And how would that hurt?

> Most people and their organizations are good, but not all.
>
> Bear in mind, a statement on the program that `this is licensed under
> the GPL' does not count.

Could you please explain what the problem is that you are talking
about?

-- 
David Kastrup

Re: CVS is the `released version'

[Robert J. Chassell]

    > Suppose a program in the package repository has been placed
    > there in order to hurt?

    And how would that hurt?

Baseless litigation that takes you away from programming.  Most likely
the victim would be American, although anyone in a country that has
accepted the WIPO treaty is at risk.

    > Bear in mind, a statement on the program that `this is licensed
    > under the GPL' does not count.

    Could you please explain what the problem is that you are talking
    about?

Baseless litigation by someone who wants to hurt and who `makes a
mistake' so the penalties for fraud are not imposed by a court.

-- 
    Robert J. Chassell                          GnuPG Key ID: 004B4AC8
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc

Re: CVS is the `released version'

[Jason Rumney]

Robert J. Chassell wrote:
> Baseless litigation by someone who wants to hurt and who `makes a
> mistake' so the penalties for fraud are not imposed by a court.
>   

Refraining from doing something because of baseless FUD would be wrong.
I don't see any reason to consider your arguments here.

Re: CVS is the `released version'

[Stefan Monnier]

> Suppose a program in the package repository has been placed there in
> order to hurt?  Most people and their organizations are good, but not all.

> Bear in mind, a statement on the program that `this is licensed under
> the GPL' does not count.

The same holds for any other GPL material distributed by the FSF but for
which the FSF does not hold the copyright.  Nothing new here.


        Stefan

Re: CVS is the `released version'

[Robert J. Chassell]

    > Bear in mind, a statement on the program that `this is licensed
    > under the GPL' does not count.

    The same holds for any other GPL material distributed by the FSF
    but for which the FSF does not hold the copyright.  Nothing new
    here.

It is likely that the FSF checked the intent of the copyright holder.
Someone downloading from a package repository may not check as
thoroughly -- for one, they may be bored by this sort of thing.  I
agree, this is not new, but the danger persists.

    Refraining from doing something because of baseless FUD would be wrong.

I agree.  The trouble is that in the contemporary US, a fear of legal
suits is not baseless, especially if you are well known.  Fortunately,
I am not.

-- 
    Robert J. Chassell                          GnuPG Key ID: 004B4AC8
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc

Re: CVS is the `released version'

[Stefan Monnier]

> It is likely that the FSF checked the intent of the copyright holder.
> Someone downloading from a package repository may not check as
> thoroughly -- for one, they may be bored by this sort of thing.  I
> agree, this is not new, but the danger persists.

Again, nothing to do with package.el.  Please don't introduce pointless and
unrelated thread in discussions.  We're already all too easily drifting
aimlessly without this kind of help,


        Stefan

Re: CVS is the `released version'

[Jason Rumney]

Robert J. Chassell wrote:
> I agree.  The trouble is that in the contemporary US, a fear of legal
> suits is not baseless, especially if you are well known.  Fortunately,
> I am not.
>   

The scenario you describes relies on the GPL not holding up in court. If
we are to make decisions on that assumption, we might as well give up now.

Re: CVS is the `released version'

[Robert J. Chassell]

[regarding baseless litigation] 

   The scenario you describes relies on the GPL not holding up in court. 

On the contrary, I am assuming we win, that the attacker goes into the
process knowing he will lose in court.

    Again, nothing to do with package.el.

That presumes that every package comes from a safe repository.  I am
sure that most will.  But the goal is to make it easier to load
packages.  That has everything to do with package.el.

All I am suggesting is a little caution, not a huge amount; that is a
defeat.  But no caution is risky, too.  People I know, like me, tend
to be on the less cautious side.  I think that is a good thing.  But
no caution at all is foolish.

Ah, you will say, nobody I know is that foolish!  But there are people
in our community who are -- that is the problem.

It is much better to be friendly and to help strangers.  It is more
efficient.  But we have got too threatening to those who prefer
feudalism, with them on top, to permit foolishness.  A little caution
is a good idea.

-- 
    Robert J. Chassell                          GnuPG Key ID: 004B4AC8
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc

Re: CVS is the `released version'

[Bob Rogers]

   From: Richard Stallman <rms@gnu.org>
   Date: Sun, 20 May 2007 13:05:23 -0400

       How about if I change things so that package.el looks at a list of
       repositories, which by default only includes the FSF-owned site?

   This might tempt redistributors (such as GNU/Linux distros) to add
   other repositories.  I don't want to ask for trouble.

Why would GNU/Linux distributors stop using their own well-established
mechanisms for publishing Emacs add-ons?  If I search for package names
containing "emacs" in the installer for a SuSE distro, for example, I
get a handful of such SuSE-distributed RPMs.  So if this is asking for
trouble, I don't see how it gets us into any *new* trouble.  ;-}

					-- Bob Rogers
					   http://rgrjr.dyndns.org/

Re: CVS is the `released version'

[Richard Stallman]

    Why would GNU/Linux distributors stop using their own well-established
    mechanisms for publishing Emacs add-ons?

I don't know what they do now.  Would you like to tell me?

      If I search for package names
    containing "emacs" in the installer for a SuSE distro, for example, I
    get a handful of such SuSE-distributed RPMs.

That doesn't have much detail, so I cannot tell if I would consider it
a problem or what.

Re: CVS is the `released version'

[Tom Tromey]

>>>>> "rms" == Richard Stallman <rms@gnu.org> writes:

>     Why would GNU/Linux distributors stop using their own well-established
>     mechanisms for publishing Emacs add-ons?

rms> I don't know what they do now.  Would you like to tell me?

Fedora's Emacs package by default removes some Emacs functionality
(tetris, on advice of lawyers) and also adds a (seemingly random) set
of additions to the system site-lisp directory.  I can send a list of
the additions if you like.  Some of them appear to be redundant with
new additions to Emacs 22 (but perhaps they are better versions of
existing modes, I don't know).

Fedora also defines a way to package Emacs add-ons.  At least AUCTeX,
Muse, and VM are packaged this way, and BBDB is in the works.
Generally these packages install into site-lisp and add a file that is
loaded by default by Emacs startup; this file handles autoloads and
the like.

Tom

Re: CVS is the `released version'

[Stefan Monnier]

> How about if I change things so that package.el looks at a list of
> repositories, which by default only includes the FSF-owned site?
> That way people can set up additional repositories as well.
> This isn't quite as friendly for users but is, IMO, workable.

Tom, I recommend that you separate issues a bit more.  Your package.el does
2 things: one is find&download packages from a repository, and the other is
install/activate/deinstall/listinstalled packages.  The two should be fairly
independent, just like apt-get and dpkg in Debian.

The dpkg-like part (the part that my install.el also intended to cover) is
the first part that really needs to be installed.  People can easily browse
the ELL already to download packages using any other random tool.  The more
difficult part for average users is to do the actual install.

Once the dpkg part is agreed upon, we can move on to the other part.


        Stefan

Re: CVS is the `released version'

[Tom Tromey]

>>>>> "Stefan" == Stefan Monnier <monnier@iro.umontreal.ca> writes:

Stefan> Tom, I recommend that you separate issues a bit more.  Your
Stefan> package.el does 2 things: one is find&download packages from a
Stefan> repository, and the other is
Stefan> install/activate/deinstall/listinstalled packages.

Ok, I see what you mean.  I will think about it a bit.

I think the reason I combined them (aside from "that's what I wanted
to do" :-) is dependency tracking.  But I suppose we can just make the
user install dependencies first.

Tom

Re: CVS is the `released version'

[Stefan Monnier]

> I think the reason I combined them (aside from "that's what I wanted
> to do" :-) is dependency tracking.  But I suppose we can just make the
> user install dependencies first.

I can see that for monsters like packages in CEDET and such, dependencies
can be a problem, but for 99% of the packages it's really the least of the
user's problems.


        Stefan

Re: CVS is the `released version'

[Xavier Maillard]

Hi,

Is there a spec that each mode/package should respect in order to
be package.el compliant ?

	Xavier
-- 
http://www.gnu.org
http://www.april.org
http://www.lolica.org

Re: CVS is the `released version'

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     rms> 1. It could reduce the incentive for people to assign copyright
>     rms> on their code.
>
>     Yeah, this is definitely to be preferred.  I'm not comfortable
>     requiring it, though, because there are very useful Emacs Lisp
>     packages which, AIUI, will never be assigned to the FSF.
>
> I'm not comfortable with having Emacs automatically install and load
> anything that isn't copyright FSF.  So if we do install a feature like
> this, it will use only one repository, on gnu.org.

I am not comfortable with having Emacs automatically install and load
anything, period.  I already expressed my opinion that requiring a
particular _repository_ would be quite a mistake.  While I agree that
something like that should likely be preconfigured to point to
something under our supervision, I consider the "fixed repository"
approach something that does not work out.  Each package should carry
with itself the information where to ask for updates.

There is a lot of code around for Emacs for which we do not even
_want_ copyright assignments and control since we have neither the
manpower nor the willingness to cater for it.  Providing for a simple
mechanism and file layout that will make it easy for the package
writers to provide the Elisp files, documentation, supplementary files
in a way where two or three Emacs commands will pull the package into
the Emacs' private site-lisp tree and byte-compile it there, would be
quite beneficial.

It would also decrease the motivation of Debian developers to come up
with their own system of placing third-party packages into Emacs
variants, a system that neither Emacs developers nor Debian developers
actually really understand in its complications and side-effects.

If we provided a standard way of getting some package layout pulled
into Emacs, possibly we could persuade Debian to stop providing Emacs
and package versions that force people to deinstall the Debian Emacs
version and replace it with a hand-installed one if they ever plan on
contributing to external Emacs projects (like AUCTeX and other).

So while I agree that the connection "central
repository"-"GNU"-"copyright FSF" seems somewhat natural, I don't want
a central repository as a necessary component of a package system or
packaging policy.

That, indeed, would not buy us so very much beyond just putting
everything into Emacs CVS itself.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: CVS is the `released version'

[Tom Tromey]

>>>>> "David" == David Kastrup <dak@gnu.org> writes:

David> I am not comfortable with having Emacs automatically install and load
David> anything, period.

Just to be clear here, package.el never automatically installs
anything.  You must ask for it using the package menu mode (or some
other install approach).  Once something is installed, it is
automatically activated when package-initialize is called -- but this
is an intentional feature.

David> I consider the "fixed repository"
David> approach something that does not work out.  Each package should carry
David> with itself the information where to ask for updates.

I considered this but rejected it for two reasons.

First, in my view it is simply more convenient for users to have a
single, pre-configured download site.  That way no configuration of
package.el is needed, it "just works".  Yes, this is slightly harder
for package maintainers, but I've tried to make package.el impose as
few hardships as possible, and I think the burden is not too great.

Second, 3rd party sites often die.  ELL has many stale links in it,
and in my view the free-for-all of the Emacs Wiki is a bit too scary
to trust blindly.  I know that the worst failure mode with a site
under my control (hosted on my web site or on savannah) is that it
will go stale -- which while lamentable at least is not a potential
security hole.

Tom

Re: CVS is the `released version'

[David Kastrup]

Tom Tromey <tromey@redhat.com> writes:

>>>>>> "David" == David Kastrup <dak@gnu.org> writes:
>
> David> I am not comfortable with having Emacs automatically install and load
> David> anything, period.
>
> Just to be clear here, package.el never automatically installs
> anything.  You must ask for it using the package menu mode (or some
> other install approach).  Once something is installed, it is
> automatically activated when package-initialize is called -- but this
> is an intentional feature.
>
> David> I consider the "fixed repository"
> David> approach something that does not work out.  Each package should carry
> David> with itself the information where to ask for updates.
>
> I considered this but rejected it for two reasons.
>
> First, in my view it is simply more convenient for users to have a
> single, pre-configured download site.  That way no configuration of
> package.el is needed, it "just works".  Yes, this is slightly harder
> for package maintainers, but I've tried to make package.el impose as
> few hardships as possible, and I think the burden is not too great.

Please take a look at how the XEmacs package system works.  It has a
central repository.  It tends to distribute outdated or non-working
code because the people maintaining the central server tend to be not
the same creating the packages.

In my opinion, it is the crucial weakness of the XEmacs package
system.  We don't want to go there.  If some package is provided
upstream, we want to have it directly usable from its default download
location.

> Second, 3rd party sites often die.  ELL has many stale links in it,
> and in my view the free-for-all of the Emacs Wiki is a bit too scary
> to trust blindly.  I know that the worst failure mode with a site
> under my control (hosted on my web site or on savannah) is that it
> will go stale -- which while lamentable at least is not a potential
> security hole.

Where is the problem with that?  Allow for fallback sites to be
specified.  The fallback may well end in a central repository, and if
you are lucky, the package drawn from there will have been updated to
know where to get more recent packages in future.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: CVS is the `released version'

[dhruva]

Hi,

On 5/21/07, David Kastrup <dak@gnu.org> wrote:
> Where is the problem with that?  Allow for fallback sites to be
> specified.  The fallback may well end in a central repository, and if
> you are lucky, the package drawn from there will have been updated to
> know where to get more recent packages in future.

Something along the lines of Debian's "apt". It is such a wonderful
tool. We could also try to have some sort of dependency check like apt
does. It sure helps people wanting to extend Emacs without having to
download, compile, file the missing package and go through that
loop... I keep promoting Debian and find it's "apt" to be the selling
point with administrators!

with best regards,
dhruva

-- 
Dhruva Krishnamurthy
Contents reflect my personal views only!

Re: CVS is the `released version'

[David Kastrup]

dhruva <dhruvakm@gmail.com> writes:

> Hi,
>
> On 5/21/07, David Kastrup <dak@gnu.org> wrote:
>> Where is the problem with that?  Allow for fallback sites to be
>> specified.  The fallback may well end in a central repository, and if
>> you are lucky, the package drawn from there will have been updated to
>> know where to get more recent packages in future.
>
> Something along the lines of Debian's "apt". It is such a wonderful
> tool.

Again: I don't want to go the way of the central repository.  95% of
what constitutes Debian is maintaining the central repository.  We
don't have those resources.

-- 
David Kastrup

Re: CVS is the `released version'

[Stephen J. Turnbull]

David Kastrup writes:

 > Please take a look at how the XEmacs package system works.  It has a
 > central repository.  It tends to distribute outdated or non-working
 > code because the people maintaining the central server tend to be not
 > the same creating the packages.

I wish you'd stop generalizing from your experience, which is limited
to AUCTeX and is unrepresentative of the general experience.
Furthermore, your reporting of the features and operation of the
XEmacs package system bears almost no resemblance to the reality.

So let's take a look at how it does work.

In fact, most of our packages (that are not maintained by the GNU
Emacs project) are maintained by their upstream maintainers.  They
generally simply make a commit to the XEmacs CVS repository, which
starts the release process using XEmacs resources, including rolling
and announcing tarballs, a pretest period, and a second announcement
when the pretest is over and the release is promoted to "public
release" (of the XEmacs package).  Only if bugs are reported, or if
the maintainer wishes to give special instructions (eg, more commits
are coming, don't release yet) is there need for anything more than a
cvs commit by upstream.  (AUCTeX differs because for many years its
upstream maintainer has been publicly at odds with the XEmacs project
and has explicitly claimed that the user who has volunteered to
maintain the XEmacs package is unqualified, and thus has forfeited
control over our package to our volunteer.)

Regarding centralization, if you want *us* to distribute packages with
storage and bandwidth contributed to *us* and want *us* to do the work
of rolling the tarballs and so on, then indeed we do insist on
checking in to our CVS.  For almost all changes to packages, it's
simply a matter of copying over the new version to a checked-out
XEmacs tree, and typing "cvs commit -m 'Release of version X.Y.Z.'" in
the package subtree of the XEmacs tree.  This is no different from
getting your package to be released as an official Emacs library,
using GNU resources: you have to check into the GNU CVS repo.

We do insist that "official XEmacs" packages be built in the context
of a full package tree, for precisely the same reasons that GNU Emacs
"wants" to be a monolithic application: Emacs Lisp provides no
facilities for proper modularization (the only namespace is the global
one), and there is no way to achieve inlining (required for Lisp
macros and extremely desirable for defsubsts) from bytecode.

Note that for this reason Tom Tromey's package.el will likely be quite
popular with upstream maintainers, compared to the XEmacs system.
It's Emacs-oriented, so you can assume that the environment will
contain all of the wonderful "stuff" distributed with Emacs.  Most of
the complexity of the XEmacs system derives from the fact that that
assumption is easily violated in a modular package system, while in
practice it won't often be a problem for users of monolithic Emacs.

For end users, in fact, there is no problem with using multiple
package archives.  (Admittedly, I'm personally not at all happy with
our UI for using multiple archives.  But that's an implementation
problem, not a bug in the basic design.)  Nor does the UI make any
attempt to distinguish between mirrors of the "official" archive and
private or upstream project archives.  VM, for example, has maintained
a private archive distributing its "latest and greatest" version as an
XEmacs package for at least 5 years.  Many users use that package in
preference to ours.  Others prefer the convenience of one stop
shopping.

 > If some package is provided upstream, we want to have it directly
 > usable from its default download location.

XEmacs's package system has that feature, and has always had it, by
design.  Cf VM.  There's nothing to stop you from distributing a
package compatible with our download and install UI.  In fact, AUCTeX,
like VM, does.  The VM and AUCTeX sites are not available from the
package configuration menu, but that's only because Kyle doesn't
particularly want the traffic, while there are "personal issues"
involved in the lack of an AUCTeX entry.

However, in the end I have to agree with Richard Stallman.  One big
problem (for GNU) with a package system is that it facilitates
distributed development and permits a general topology (rather than a
star) for the distribution network.  Thus it undermines the incentive
to work in the context of the Emacs project and to assign code to the
FSF.  That's inconsistent with my understanding of the goals of GNU,
and therefore of the Emacs project.

Stefan Monnier is also correct that properly supporting a package
system requires that exported APIs be designated and respected (ie,
backwards compatibility be maintained in the face of clearly better
alternatives).  In XEmacs practice, any API used by a package in the
CVS package repository is exported, unless we've explicitly labelled
it as internal.  In effect, any third party can "out" an API simply by
calling it.  Conflicts are rare, but annoying when they do occur.
This is a perennial complaint of core developers in XEmacs (especially
Ben Wing, but by no means limited to him).  Since GNU wants to
encourage development to happen inside of GNU, not outside of it, it
seems silly to constrain Emacs that way.

I conclude that until distributed development becomes an explicit goal
of the Emacs project, a package system is generally counterproductive
to the objectives it espouses (by which I mean advocating free
software and supporting organizations in the free software movement,
and developing Emacs itself as opposed to third party libraries).

Re: CVS is the `released version'

[David Kastrup]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> David Kastrup writes:
>
>  > Please take a look at how the XEmacs package system works.  It
>  > has a central repository.  It tends to distribute outdated or
>  > non-working code because the people maintaining the central
>  > server tend to be not the same creating the packages.
>
> I wish you'd stop generalizing from your experience, which is
> limited to AUCTeX and is unrepresentative of the general experience.

I don't see how it would be unrepresentative.  Please name some
packages where

a) the upstream author has not taken upon himself the burden of
becoming an XEmacs developer including write access to the XEmacs
CVS repository and learning the structure of the package build system

b) the package is kept reasonably uptodate

Could you name externally distributed packages (useful for other Emacs
variants) where the structure of the XEmacs package is not different
from what works unmodified for the distribution of other versions?
There is X-Symbol, but its Emacs install procedure is a hand-crafted
process that is made more complicated by the XEmacs package structure.

> Furthermore, your reporting of the features and operation of the
> XEmacs package system bears almost no resemblance to the reality.
>
> So let's take a look at how it does work.
>
> In fact, most of our packages (that are not maintained by the GNU
> Emacs project) are maintained by their upstream maintainers.  They
> generally simply make a commit to the XEmacs CVS repository,

See?  You require
a) the upstream developers to have CVS write access
b) the package to be structured for the XEmacs packagae CVS tree which is
c) completely different from the actual package layout in the
   installed tree, meaning that this particular layout is useless
   _except_ as part of the _XEmacs_ package system.

> which starts the release process using XEmacs resources, including
> rolling and announcing tarballs, a pretest period, and a second
> announcement when the pretest is over and the release is promoted to
> "public release" (of the XEmacs package).  Only if bugs are
> reported, or if the maintainer wishes to give special instructions
> (eg, more commits are coming, don't release yet) is there need for
> anything more than a cvs commit by upstream.  (AUCTeX differs
> because for many years its upstream maintainer has been publicly at
> odds with the XEmacs project and has explicitly claimed that the
> user who has volunteered to maintain the XEmacs package is
> unqualified,

That's what the _user_ himself has stated several times, yet he has
seen little help.  Don't blame me for repeating Uwe's statement.  And
it is not like I have ever discouraged Uwe for his work.  I have
rather complained about the lack of help he is seeing from XEmacs
developers.

> and thus has forfeited control over our package to our volunteer.)

Stephen, cut the propaganda.  None of the XEmacs developers could be
bothered updating AUCTeX which had fallen _several_ years behind for
that reason.  I asked _repeatedly_ on the XEmacs developer list, over
a long period.

Finally an AUCTeX user, Uwe, volunteered to _try_ his hand and he has
repeatedly stated himself that he was quite out of his depth.
Nevertheless, he managed to get out some releases with a large
time-delay.  It was, however, relatively obvious that he was not
getting much help from XEmacs developers.  Since preview-latex already
had the infrastructure for building an XEmacs package layout included
(from the time an XEmacs developer helped porting it), when we merged
preview-latex into AUCTeX, we have kept this infrastructure intact.
One of the motivations was to be able to produce a complete XEmacs
package as a _target_ for those having to maintain the XEmacs package
in the XEmacs CVS manner.

preview-latex is not a simple package, and the installation process
has a lot of flexibilities.  Nevertheless, we have been able to come
up with a configuration (after several iterations) that produces a
ready-to-run XEmacs package usable for pretty much all configurations.

In spite of having our automated build process to take as an example,
in spite of having a ready-made package (which according to XEmacs
terminology is complete (citing the GPL) "with all the source code for
all modules it contains, plus any associated interface definition
files, plus the scripts used to control compilation and installation
of the executable") and in spite of both Uwe as well as another XEmacs
developer trying, they have not been able to create the files and/or
process of reproducing the package which we already provide in a final
form.

> Regarding centralization, if you want *us* to distribute packages
> with storage and bandwidth contributed to *us* and want *us* to do
> the work of rolling the tarballs and so on, then indeed we do insist
> on checking in to our CVS.

It does not work since the CVS requires a completely different
directory layout from the installed package.  So it is required to
have
a) a source tree modeled after the XEmacs CVS package source tree
b) a final package layout modeled after the XEmacs package layout.

If you have just b), you can't transform it into a) (or we would have
had an uptodate AUCTeX distributed long long ago).  And if you don't
use the rigid XEmacs package tree layout for going to b), you can't
get to a) easily either.

And this is simply a mistake.

Now the current approaches I see with package systems for Emacs at
least avoid the mistake of demanding a source package layout that is
fundamentally different from the finished package layout and can't be
reproduced from the latter.

That is one design mistake less to cater for.

But the centralized repository requirement, in my book, is another
that is asking for trouble.

> For almost all changes to packages, it's simply a matter of copying
> over the new version to a checked-out XEmacs tree, and typing "cvs
> commit -m 'Release of version X.Y.Z.'"  in the package subtree of
> the XEmacs tree.  This is no different from getting your package to
> be released as an official Emacs library, using GNU resources: you
> have to check into the GNU CVS repo.

Which does not have a different layout from the distributed packages
and does not require separate description files and Makefile rules.

Still, the target of a package system, if any, is _not_ to require
including everything into Emacs.  So saying that your system is as
easy as just dropping everything into Emacs (which it isn't) is
tantamount to saying that its complications are not offset by making
maintenance simpler.

> Note that for this reason Tom Tromey's package.el will likely be
> quite popular with upstream maintainers, compared to the XEmacs
> system.

Well, there is nothing wrong in trying to avoid what I consider design
mistakes in the XEmacs system.  Certainly package.el seems like an
improvement over the XEmacs system for most uses.  That does not mean
that one should not try still making it better for common use cases
while one is still in the design phase.

>  > If some package is provided upstream, we want to have it directly
>  > usable from its default download location.
>
> XEmacs's package system has that feature, and has always had it, by
> design.  Cf VM.

Uh no.  VM does not tell the package system where its canonical
download location is supposed to be.  One has to manually configure
that.

> There's nothing to stop you from distributing a package compatible
> with our download and install UI.  In fact, AUCTeX, like VM, does.
> The VM and AUCTeX sites are not available from the package
> configuration menu, but that's only because Kyle doesn't
> particularly want the traffic, while there are "personal issues"
> involved in the lack of an AUCTeX entry.

What personal issues?

> However, in the end I have to agree with Richard Stallman.  One big
> problem (for GNU) with a package system is that it facilitates
> distributed development and permits a general topology (rather than
> a star) for the distribution network.  Thus it undermines the
> incentive to work in the context of the Emacs project and to assign
> code to the FSF.  That's inconsistent with my understanding of the
> goals of GNU, and therefore of the Emacs project.

Yes and no.  Part of the strength of Emacs is its extensibility which
leads to a large amount of one-shot code for special solutions that
really has no sensible place in a centrally maintained repository, and
which is not strategically important to the GNU project.  Being able
to provide such code in a form which could easily be pulled into an
Emacs without much manual work would be a boon.

> I conclude that until distributed development becomes an explicit
> goal of the Emacs project, a package system is generally
> counterproductive to the objectives it espouses (by which I mean
> advocating free software and supporting organizations in the free
> software movement, and developing Emacs itself as opposed to third
> party libraries).

I am more thinking in the form of "disjoint" rather than "distributed"
development.  Stuff which you might very well decide you don't need.

-- 
David Kastrup

Re: CVS is the `released version'

[Richard Stallman]

    Please take a look at how the XEmacs package system works.  It has a
    central repository.  It tends to distribute outdated or non-working
    code because the people maintaining the central server tend to be not
    the same creating the packages.

You previously explained that this is because making the XEmacs package
requires doing substantial work on the code.  We are moving to reduce
to zero the amount of "packaging" required.  All that would be necessary
is to install the new version in the standard repository.  Since this
is easy, people would do it often.  We could even let the maintainers
of the package itself do so.

Re: CVS is the `released version'

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     Please take a look at how the XEmacs package system works.  It
>     has a central repository.  It tends to distribute outdated or
>     non-working code because the people maintaining the central
>     server tend to be not the same creating the packages.
>
> You previously explained that this is because making the XEmacs
> package requires doing substantial work on the code.  We are moving
> to reduce to zero the amount of "packaging" required.  All that
> would be necessary is to install the new version in the standard
> repository.  Since this is easy, people would do it often.

If they have access and are interested in doing it.  One of the
package-centric projects I am involved with is TeX.  There is a server
CTAN (comprehensive TeX archive network) which takes contributions in
whatever form people want to make.  There is no really standardized
package format.  A distribution, TeXlive, is usually made yearly, and
it takes a bunch of volunteers to check stuff from CTAN into TeXlive,
update the TPM (TeX package manager files, XML files which basically
say what goes where in the installed tree) and integrate stuff.

CTAN basically places no burden on the submitter at all concerning the
structuring of the package, and licensing (there is a non-free
hierarchy for stuff that can't be redistributed and changed freely) or
copyrights.  Even though contributing to it is basically hassle-free,
it is probably "only" 90% of all interesting packages that are there,
and reasonably up to date.  TeXlive also manages to be mostly up to
date (apart from some oversights).  Contributors are usually asked to
suggest proper installation points in the CTAN hierarchy, as well as
in a running TeX system.

> We could even let the maintainers of the package itself do so.

If we provide Emacs commands that produce a package _and_ can install
into an Emacs CVS work copy (probably generating appropriate ChangeLog
entries semi-automatically) _and_ can install into local directories
for a running Emacs, all from the same package source tree, we
basically are at a point where contributing to Emacs CVS is a
zero-pain procedure once one finished testing and installing locally.
If those commands don't do much more than a recursive copy, so much
the better: it would mean that one could convert one form into a
different one easily, not requiring starting from a "canonical" source
version.

I would guess that such a system would tend to get us more rather than
fewer contributions.

-- 
David Kastrup

Re: CVS is the `released version'

[Richard Stallman]

    If we provide Emacs commands that produce a package _and_ can install
    into an Emacs CVS work copy (probably generating appropriate ChangeLog
    entries semi-automatically) _and_ can install into local directories
    for a running Emacs, all from the same package source tree, we
    basically are at a point where contributing to Emacs CVS is a
    zero-pain procedure once one finished testing and installing locally.
    If those commands don't do much more than a recursive copy, so much
    the better: it would mean that one could convert one form into a
    different one easily, not requiring starting from a "canonical" source
    version.

I am confused by this response, because I was talking about
installation into a separate repository of packages not included in
Emacs itself, but you're talking about installation into Emacs.

That doesn't mean your idea is not a good one, but I am not sure
what its point is.

package.el (was: Re: CVS is the `released version')

[David Reitter]

Hi Tom,

I just had a look at package.el. A few comments:

The install instructions say:

> If you don't know what "eval" means, it means that you should copy  
> this into your *scratch* buffer, move your cursor just after the  
> final closing paren, and type C-j.

*scratch* is not guaranteed to be in emacs-lisp-mode. So C-j might  
not work. M-x eval-region would!

 From your installer file:

> (expand-file-name "~/.emacs.d/elpa")

please don't assume that this directory is something where you can  
(or the user wants to) install things. There should be a  
customization variable for this. This applies to package.el itself as  
well, where you have a defvar, not a defcustom, for package-user-dir.

In package.el, I'm not sure what's going on with `package-activated- 
list', but you seem to make assumptions about which packages are  
installed by default. Does your code also check for actually  
installed files? Emacs distributions may come with other things like  
AUCTeX, JDEE, and many other packages already installed (and this may  
or may not have been done in a way compatible with package.el).

I hope that helps, and keep working on this - I think it's a good idea.

Re: package.el

[Tom Tromey]

>>>>> "David" == David Reitter <david.reitter@gmail.com> writes:

David> I just had a look at package.el. A few comments:

Thanks for your time and your feedback.

If emacs-devel folks don't like this traffic here we can move it
elsewhere.  `elpa@tromey.com' is my package.el address.

>> If you don't know what "eval" means, it means that you should copy
>> this into your *scratch* buffer, move your cursor just after the
>> final closing paren, and type C-j.

David> *scratch* is not guaranteed to be in emacs-lisp-mode. So C-j might
David> not work. M-x eval-region would!

I wasn't aware of this.  Is this a common situation?  Those
instructions are intended for people who know very little about Emacs;
are they likely to have changed the mode for *scratch*?

David> From your installer file:
David> (expand-file-name "~/.emacs.d/elpa")
David> please don't assume that this directory is something where you can
David> (or the user wants to) install things.

David> There should be a customization variable for this. This applies
David> to package.el itself as well, where you have a defvar, not a
David> defcustom, for package-user-dir.

Yes, I agree.  I don't know much about custom (my last emacs lisp
hacking experience predates the existence of custom -- sad but true).
But I will learn and I'll make the appropriate fix.

However, for the installer, I think this is an ok choice.  I don't see
how we would support customizing the package install directory before
actually installing package.el.  And, I suspect users who know about
and use features like this probably won't have much trouble hand
installing package.el.

What do you think about this?

David> In package.el, I'm not sure what's going on with `package-activated- 
David> list', but you seem to make assumptions about which packages are
David> installed by default.

Yes.  package.el knows a bit about which packages are shipped as part
of Emacs.  This supports one of the use cases I was interested in,
something I've run into a reasonable number of times.

The use case is this: suppose I install some package, for example ERC,
in my $HOME.  Then later I upgrade to Emacs 22, which includes ERC.
At this point I want my private ERC to be deactivated in favor of
Emacs' built-in version.  But then later I may upgrade to a later ERC,
in which case I want to use my newer private copy again.

In package.el this is solved by knowing the versions of large packages
which are included in Emacs.  This list isn't complete though -- known
bug.

David> Does your code also check for actually installed files?

Nope.  It could though, I think, perhaps not without drastically
slowing down Emacs startup.  I want to avoid that as much as possible.
I suppose my ideal situation here would be for distros to support
package.el directly (my real ideal was to get this into Emacs itself
but that is looking less likely :-).  This is intentionally not hard
to do... but I think it is still a bit early to approach them on this
topic.

Tom

Re: package.el

[David Kastrup]

Tom Tromey <tromey@redhat.com> writes:

> David> *scratch* is not guaranteed to be in emacs-lisp-mode. So C-j might
> David> not work. M-x eval-region would!
>
> I wasn't aware of this.  Is this a common situation?  Those
> instructions are intended for people who know very little about
> Emacs; are they likely to have changed the mode for *scratch*?

Primarily people with little knowledge about Emacs would be tempted to
change the mode for *scratch*...  On the other hand, they would be
likely to do a lot of other things one can't possibly guess in
advance.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: package.el

[David Reitter]

On 21 May 2007, at 18:40, Tom Tromey wrote:

> David> *scratch* is not guaranteed to be in emacs-lisp-mode. So C-j  
> might
> David> not work. M-x eval-region would!
>
> I wasn't aware of this.  Is this a common situation?  Those
> instructions are intended for people who know very little about Emacs;
> are they likely to have changed the mode for *scratch*?

default-major-mode's default value is text-mode in Aquamacs.  
*scratch* is in text-mode by default.

> Yes, I agree.  I don't know much about custom (my last emacs lisp
> hacking experience predates the existence of custom -- sad but true).
> But I will learn and I'll make the appropriate fix.
>
> However, for the installer, I think this is an ok choice.

Well, in a distribution, this is what one wants to customize - simply  
because ~/.emacs.d is not a [standard] directory on all operating  
systems. I don't know what Windows does, but on the Mac, such  
extensions go into ~/Applications/Application Support/Emacs/... -  
which is something a CVS (GNU) Emacs doesn't do. But a distribution  
of GNU Emacs (such as Aquamacs) knows these directories.

> and use features like this probably won't have much trouble hand
> installing package.el.

Yes, if it's a standard package that provides a new feature - sure no  
problem. That's what would be included in a distro anyways.

> Yes.  package.el knows a bit about which packages are shipped as part
> of Emacs.  This supports one of the use cases I was interested in,
> something I've run into a reasonable number of times.

OK, please don't forget cases where a distribution installs  
additional packages. Both distributions on the Mac do that, and I  
presume the Windows binaries come with some add-ons, too. And you,  
yourself, mentioned Fedora's dislike for Tetris, etc.

> In package.el this is solved by knowing the versions of large packages
> which are included in Emacs.  This list isn't complete though -- known
> bug.

Yes, bug. I would check the versions of all installed packages at  
compile time (install time), going through Emacs' load path.
Or, perhaps better, you check for installed versions just when you  
actually need to know, i.e., when the user wants to install another  
package.
As a distributor, I would not enable a feature that will slow down  
the application startup.

> I suppose my ideal situation here would be for distros to support
> package.el directly (my real ideal was to get this into Emacs itself
> but that is looking less likely :-).

It's more realistic to make package.el work in the way Emacs already  
finds and loads its packages, rather than requiring distributors to  
maintain a separate database of file versions (even though that would  
be a sensible thing to do). This could be done via a standard symbol  
`feature-version' where "feature" stands for the name of the feature  
that is `provide'd, or via the subfeatures argument to `provide'. I  
don't know what is already in place in package.el.

Re: package.el

[Tom Tromey]

>>>>> "David" == David Reitter <david.reitter@gmail.com> writes:

David> default-major-mode's default value is text-mode in Aquamacs.
David> *scratch* is in text-mode by default.

Ok.  I will update the text to account for this somehow.

David> Well, in a distribution, this is what one wants to customize -
David> simply because ~/.emacs.d is not a [standard] directory on all
David> operating systems.

I simply followed existing practice that I found in Emacs.  FWIW I
think it would make sense to make this a customizable setting used
everywhere that "~/.emacs.d" is currently used.

Does Aquamacs have a setting for this?  package.el could conditionally
use that.

David> OK, please don't forget cases where a distribution installs
David> additional packages. Both distributions on the Mac do that, and I
David> presume the Windows binaries come with some add-ons, too. And you,
David> yourself, mentioned Fedora's dislike for Tetris, etc.

Yes.  The issue is expressing this in an efficient way to package.el.

David> It's more realistic to make package.el work in the way Emacs already
David> finds and loads its packages, rather than requiring distributors to
David> maintain a separate database of file versions (even though that would
David> be a sensible thing to do). This could be done via a standard symbol
David> feature-version' where "feature" stands for the name of the feature
David> that is `provide'd, or via the subfeatures argument to `provide'. I
David> don't know what is already in place in package.el.

Currently this is done by loading the "-pkg.el" file from the package,
which then invokes define-package.

This is ok if you don't have a huge number of packages.  If we ever
get there then perhaps I'll need to think about a new approach.

I don't see how feature-version would be defined until a package is
loaded -- but that is what we want to avoid.

My (former) plan for incorporating this into the core was to extract
this info when Emacs is built.  Anyway, I'm open to suggestions but,
again, I'm a bit unsure whether this is the appropriate forum for
discussion.

Tom

Re: package.el

[Davis Herring]

> David> Well, in a distribution, this is what one wants to customize -
> David> simply because ~/.emacs.d is not a [standard] directory on all
> David> operating systems.
>
> I simply followed existing practice that I found in Emacs.  FWIW I
> think it would make sense to make this a customizable setting used
> everywhere that "~/.emacs.d" is currently used.
>
> Does Aquamacs have a setting for this?  package.el could conditionally
> use that.

This (the customizable setting) has been discussed before[1], and I even
offered to go find all the hardcoded ~/.emacs.d/ usages, but there wasn't
much evident interest.  Is there now, especially given the issue of
differing standards among OSes?

Davis

[1] http://lists.gnu.org/archive/html/emacs-devel/2005-08/msg00317.html

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: package.el

[Lennart Borgman (gmail)]

Davis Herring wrote:
>> David> Well, in a distribution, this is what one wants to customize -
>> David> simply because ~/.emacs.d is not a [standard] directory on all
>> David> operating systems.
>>
>> I simply followed existing practice that I found in Emacs.  FWIW I
>> think it would make sense to make this a customizable setting used
>> everywhere that "~/.emacs.d" is currently used.
>>
>> Does Aquamacs have a setting for this?  package.el could conditionally
>> use that.
> 
> This (the customizable setting) has been discussed before[1], and I even
> offered to go find all the hardcoded ~/.emacs.d/ usages, but there wasn't
> much evident interest.  Is there now, especially given the issue of
> differing standards among OSes?


Sounds like a good change to me.

Re: package.el

[Tom Tromey]

>>>>> "Davis" == Davis Herring <herring@lanl.gov> writes:

Davis> This (the customizable setting) has been discussed before[1],
Davis> and I even offered to go find all the hardcoded ~/.emacs.d/
Davis> usages, but there wasn't much evident interest.  Is there now,
Davis> especially given the issue of differing standards among OSes?

Ah, cool.  I wasn't aware of this.

Today I made a quick pass over Emacs to fix this.  I haven't tested my
patch yet, since I ran into a few difficulties:

* xterm.c uses ~/.emacs.d:

          char *file = "~/.emacs.d/gtkrc";

  I'm not familiar with Emacs internals but I would guess this is run
  before .emacs -- so I don't see how the user could customize this...?
  But for the Aquamacs case I suppose this doesn't matter.

* emacsclient.c:

          sprintf (path, "%s/.emacs.d/server/%s", home, server_file);

  We'd need an environment variable or command line argument here.
  Also some -- but not all -- of the Emacs lisp code uses _emacs_d on
  'ms-dos.  Is this different from Windows?  Does emacsclient work on
  ms-dos?  (If so then the code looks incorrect...)

* Lots of places hard-code .emacs.d, some use _emacs_d, and one uses
  convert-standard-filename.  My patch uses option #2 but maybe
  convert-standard-filename is better?

* I wasn't sure what to do about the doc strings and the Texinfo.
  Should they all mention `user-emacs-directory'?  Or just leave them
  as-is, mentioning ~.emacs.d/, and let the reader figure it out?

* More trivially, what :group should the new user-emacs-directory
  defcustom be in?

Anyway I am happy to send the patch to anybody interested.  And I'm
going to do a bit of testing of it "soon" :)

Tom

Re: package.el

[Richard Stallman]

    * Lots of places hard-code .emacs.d, some use _emacs_d, and one uses
      convert-standard-filename.  My patch uses option #2 but maybe
      convert-standard-filename is better?

What is crucial is that all uses of this directory operate compatibly.
They should all do what `convert-standard-filename' would do.

It is not crucial that they do this by calling
`convert-standard-filename', and emacsclient can't do that.  But it
would be nice if they do call `convert-standard-filename' whenever
that is feasible.

    * I wasn't sure what to do about the doc strings and the Texinfo.
      Should they all mention `user-emacs-directory'?  Or just leave them
      as-is, mentioning ~.emacs.d/, and let the reader figure it out?

emacsclient.c won't be able to use `user-emacs-directory'
just as it won't be able to call `convert-standard-filename'.

Re: package.el

[David Reitter]

On 21 May 2007, at 23:51, Tom Tromey wrote:

> I simply followed existing practice that I found in Emacs.  FWIW I
> think it would make sense to make this a customizable setting used
> everywhere that "~/.emacs.d" is currently used.
> Does Aquamacs have a setting for this?  package.el could conditionally
> use that.

No, and I think we should just come up with a setting in the trunk  
rather than making a change downstream.
It's only a handful of places where "~/emacs.d" is assumed (as default).

> Currently this is done by loading the "-pkg.el" file from the package,
> which then invokes define-package.

..but that would mean that each package has to have an extra file.  
Many packages consist of only a single .el source file, which then  
doesn't even need to be tar'ed for distribution.

> I don't see how feature-version would be defined until a package is
> loaded -- but that is what we want to avoid.

How about looking for some tags ;; pkg:define and ;; pkg:end inside  
the source file, and then evaluating only what's within those tags?

Re: package.el

[Tom Tromey]

>>>>> "David" == David Reitter <david.reitter@gmail.com> writes:

>> Currently this is done by loading the "-pkg.el" file from the package,
>> which then invokes define-package.

David> ..but that would mean that each package has to have an extra file.
David> Many packages consist of only a single .el source file, which then
David> doesn't even need to be tar'ed for distribution.

Yes.  Please look at package.el.  This is what it does; for single
files it generates the -pkg.el and -autoloads.el files.  For
multi-file packages, my belief is that adding a single file containing
a single form is not a major maintenance burden.

>> I don't see how feature-version would be defined until a package is
>> loaded -- but that is what we want to avoid.

David> How about looking for some tags ;; pkg:define and ;; pkg:end inside
David> the source file, and then evaluating only what's within those tags?

package.el uses the comments to generate the -pkg.el file.

I'm reasonably sure that I don't want to do this scanning every time
Emacs starts up.  But I admit I have not benchmarked the scanning
approach.

Tom

Re: package.el

[Stephen J. Turnbull]

Tom Tromey writes:

 > I'm reasonably sure that I don't want to do this scanning every time
 > Emacs starts up.  But I admit I have not benchmarked the scanning
 > approach.

XEmacs does do a lot of scanning, and it has been a source of
complaints.  But IIRC the problem was that XEmacs keeps each package
in a separate directory (actually, several of them, since it emulates
the standard layout of GNU Emacs with subdirectories of lisp/ for
package Lisp, subdirectories of etc/ for miscellaneous package data,
and so on).  Searching through that to determine which subdirectories
are actually package directories and should be on load-path was what
took the most time.

The original scheme was fully recursive requiring stats of all files
to find subdirectories for possible recursion.  Substantial savings
were achieved by limiting the search depth (currently to children of
the lisp/ directory itself).  Currently most XEmacs users seem to
consider the additional startup time acceptable, especially on fast
machines with Unix-style file systems, but I suspect for even a
moderate number of packages, Emacs users would detect a lag, since
Emacs's startup is snappier than XEmacs's.

David Kastrup had several suggestions for how to speed up XEmacs's
start time, which would probably apply to package.el, too.  IIRC they
were to collect package auto-autoloads and custom-loads into a single
file, and to put all package Lisp into a single directory to avoid
recursive searching.

Re: package.el

[Stefan Monnier]

> I'm reasonably sure that I don't want to do this scanning every time
> Emacs starts up.  But I admit I have not benchmarked the scanning
> approach.

I'm reasonably sure that doing any scanning at startup time is a bad idea.
Do the scan at package-activation time and be done with it,


        Stefan

Re: package.el

[David Kastrup]

David Reitter <david.reitter@gmail.com> writes:

> On 21 May 2007, at 18:40, Tom Tromey wrote:
>
>> David> *scratch* is not guaranteed to be in emacs-lisp-mode. So C-j
>> might
>> David> not work. M-x eval-region would!
>>
>> I wasn't aware of this.  Is this a common situation?  Those
>> instructions are intended for people who know very little about Emacs;
>> are they likely to have changed the mode for *scratch*?
>
> default-major-mode's default value is text-mode in Aquamacs.
> *scratch* is in text-mode by default.

I doubt it should be the job of package.el's instructions to
anticipate such ideosyncratic setting choices.  Since you would
presumably package package.el into Aquamacs, anyway, in order to cater
for your prospective not-so-experienced user audience, this would
appear to be a non-issue.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: CVS is the `released version'

[Richard Stallman]

    There is a lot of code around for Emacs for which we do not even
    _want_ copyright assignments and control since we have neither the
    manpower nor the willingness to cater for it.

We want copyright assignments for any packages that are important
(which includes the popular ones), and any code we might want to
install.

It is true that many Lisp programs are posted which are not quite as
interesting.  However, if we encourage people not to sign assignments
when we need them.

Re: CVS is the `released version'

[Richard Stallman]

    It is only needed for multi-file packages.  Essentially package.el
    needs 3 pieces of information about a package: its name, its version
    number, and its requirements.  For a single-file package these are
    extracted from comments; package.el defines a new comment header
    ("Package-Requires") for requirements, but so far I think this is
    unused.

    For a multi-file package the problem is just knowing where to look to
    get this information.  It seemed simplest to have the package
    maintainer provide it in a well-known place.

I think I understand.  Can you show me the specs for define-package?

Re: CVS is the `released version'

[Tom Tromey]

>>>>> "rms" == Richard Stallman <rms@gnu.org> writes:

rms> I think I understand.  Can you show me the specs for define-package?

Here's an extract from package.el.
Hmm, I am very inconsistent about variable naming here, sorry.  And
the documentation is not entirely clear -- each OTHER-PACKAGE is a symbol.

    (defun define-package (name-str version-string
                                &optional docstring
                                &optional requirements)
      "Define a new package.
    NAME is the name of the package, a string.
    VERSION-STRING is the version of the package, a dotted sequence
    of integers.
    DOCSTRING is the optional description.
    REQUIREMENTS is a list of requirements on other packages.
    Each requirement is of the form (OTHER-PACKAGE \"VERSION\")."

This particular example was generated by package.el from
javascript.el:

    (define-package "javascript" "1.99.8" "Major mode for editing JavaScript source text" nil)

Here's another example, this time from lisppaste.  In this case,
lisppaste requires xml-rpc:

    (define-package "lisppaste" "1.2" "Interact with the lisppaste pastebot via XML-RPC." (quote ((xml-rpc "1.6.4"))))


There are some other issues we probably need to work out before we can
seriously contemplate adding package.el to Emacs.  I'm happy to
discuss them here if you like, just let me know... is this the right
time to discuss it?

Also, perhaps someone should review the code, as I am only an
occasional Emacs Lisp hacker.

Tom

Re: CVS is the `released version'

[Richard Stallman]

It seems wasteful to have a file just for this define-package.  Why
not get the info out of the .el files just as for a one-file package?

It could look at all the .el files and verify that they all agree.  If
they don't, it could print an error message.  If it finds different
package names in various files, it could treat them as separate packages.

I think this would in most cases simplify the packaging.

Re: CVS is the `released version'

[Tom Tromey]

>>>>> "rms" == Richard Stallman <rms@gnu.org> writes:

rms> It seems wasteful to have a file just for this define-package.  Why
rms> not get the info out of the .el files just as for a one-file package?

rms> It could look at all the .el files and verify that they all agree.  If
rms> they don't, it could print an error message.  If it finds different
rms> package names in various files, it could treat them as separate packages.

rms> I think this would in most cases simplify the packaging.

Thanks, I will think about this.  Single-file packages were actually
an add-on to package.el, initially I was only going to support tar
archives.

Right now package.el manages packages in a very simple way -- they are
just unpacked underneath ~/.emacs.d/elpa/, and there is a
straightforward correspondence between package name+version and
directory name.  Having multiple packages in a single directory would
seem to require changing this... not sure I want to do that.  But I
will brainstorm a bit.

Tom

Re: CVS is the `released version'

[Stefan Monnier]

> It seems wasteful to have a file just for this define-package.  Why
> not get the info out of the .el files just as for a one-file package?

I don't think the waste is very significant.  Butm I agree that package.el
could simply look for a define-package call in every .el file.  And it could
simply report an error if there are 2 or more such calls.

> It could look at all the .el files and verify that they all agree.  If
> they don't, it could print an error message.  If it finds different
> package names in various files, it could treat them as separate packages.

I think tht supporting several "packages" inside a single tarball will
complicate matters significantly.  OTOH, some packages include other
packages for the user's (in)convenience, e.g. ProofGeneral includes a copy
of X-Symbol in its tarball, so package.el somehow do something intelligent
in such cases.  Maybe it can recognize that it's in a dubdirectory of its
own and move it out or something like that.


        Stefan

Re: CVS is the `released version'

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> It seems wasteful to have a file just for this define-package.  Why
>> not get the info out of the .el files just as for a one-file package?
>
> I don't think the waste is very significant.  Butm I agree that
> package.el could simply look for a define-package call in every .el
> file.  And it could simply report an error if there are 2 or more
> such calls.

Could also be information in a comment, properly formatted.

-- 
David Kastrup

Re: CVS is the `released version'

[Stefan Monnier]

>>> It seems wasteful to have a file just for this define-package.  Why
>>> not get the info out of the .el files just as for a one-file package?
>> 
>> I don't think the waste is very significant.  Butm I agree that
>> package.el could simply look for a define-package call in every .el
>> file.  And it could simply report an error if there are 2 or more
>> such calls.

> Could also be information in a comment, properly formatted.

Indeed, probably using the same format as is currently used for
single-file packages.


        Stefan

Re: CVS is the `released version'

[Tom Tromey]

>>>>> "Stefan" == Stefan Monnier <monnier@iro.umontreal.ca> writes:

Stefan> I think tht supporting several "packages" inside a single
Stefan> tarball will complicate matters significantly.  OTOH, some
Stefan> packages include other packages for the user's
Stefan> (in)convenience, e.g. ProofGeneral includes a copy of X-Symbol
Stefan> in its tarball, so package.el somehow do something intelligent
Stefan> in such cases.  Maybe it can recognize that it's in a
Stefan> dubdirectory of its own and move it out or something like
Stefan> that.

Yeah -- I considered a lot of different scenarios when initially
writing package.el.  Not just things like the above but also things
like anti-dependencies, version dependency relations other than ">=",
elisp in subdirectories, optionally compiled elisp, optional
dependencies, sub-packages, ...

In the end I decided to start with something simple and see how that
worked out.  I don't know about ProofGeneral, but my initial reaction
here would be to try to convince them to package X-Symbol as a
separate package.

In general I think putting dependencies into a package like this is a
reaction to the lack of any sort of extension management in Emacs.  In
the current state of affairs it looks more convenient for users to do
this... but this is part of what I'd like to change.

I'm certainly not averse to adding features, but I'd prefer to push
the KISS approach as long as possible.

For cases like ProofGeneral, they could make one set of packages for
ELPA and another for general ("old school") download.

Tom

Re: CVS is the `released version'

[Richard Stallman]

I'm in favor of dealing first with convenient installation of one
package, and worrying about things like dependencies later.

Re: CVS is the `released version'

[Trent Buck]

Richard Stallman <rms@gnu.org> writes:

> In that case, I think the real proposal is not "add a package system
> to Emacs" but rather "set up a standard site for Emacs add-ons".

Agreed.

> If the add-ons are put in such a web site, finding and installing them
> would be much easier.  Maybe it is worth doing that, though calling it
> a "package system" seems like hype.
>
> But there are two important non-technical problems with this approach.
>
> 1. It could reduce the incentive for people to assign copyright on
> their code.
>
> 2. It would mean that Emacs refers people very strongly to a site
> that isn't run by the GNU Project.  I don't know what their policies
> are.  But even if they are good, now, we have no way to assure that
> remains so.
>
> These problems would be eliminated if we put the package repository on
> gnu.org and limit it to packages that are copyright FSF.

Would it be acceptable to have two repositories "main" and "non-fsf",
both hosted on gnu.org, and only have the former enabled by default?
That is, packages in "non-fsf" would not be listed or installable
unless the user explicitly added something like this to their .emacs:

    (add-to-list 'package-repositories "http://elpa.gnu.org/non-fsf")

That way Free software packages that are NOT assigned to the FSF (such
as paredit, which is declares itself to be in the Public Domain), can
still be installed easily by users via the package.el framework, but
only after the user explicitly says "please enable installation of
Free, but non-FSF packages".  It would also make it easy to move a
package into "main" once the paperwork was done by simply changing a
few headers -- the rest of the package.el integration would already
have been done and tested in the "non-fsf" repository.
-- 
Trent Buck

Re: CVS is the `released version'

[David Kastrup]

Trent Buck <trentbuck@gmail.com> writes:

> Richard Stallman <rms@gnu.org> writes:
>
>> In that case, I think the real proposal is not "add a package system
>> to Emacs" but rather "set up a standard site for Emacs add-ons".
>
> Agreed.
>
>> If the add-ons are put in such a web site, finding and installing them
>> would be much easier.  Maybe it is worth doing that, though calling it
>> a "package system" seems like hype.
>>
>> But there are two important non-technical problems with this approach.
>>
>> 1. It could reduce the incentive for people to assign copyright on
>> their code.
>>
>> 2. It would mean that Emacs refers people very strongly to a site
>> that isn't run by the GNU Project.  I don't know what their policies
>> are.  But even if they are good, now, we have no way to assure that
>> remains so.
>>
>> These problems would be eliminated if we put the package repository on
>> gnu.org and limit it to packages that are copyright FSF.
>
> Would it be acceptable to have two repositories "main" and
> "non-fsf", both hosted on gnu.org, and only have the former enabled
> by default?  That is, packages in "non-fsf" would not be listed or
> installable unless the user explicitly added something like this to
> their .emacs:
>
>     (add-to-list 'package-repositories "http://elpa.gnu.org/non-fsf")
>
> That way Free software packages that are NOT assigned to the FSF
> (such as paredit, which is declares itself to be in the Public
> Domain), can still be installed easily by users via the package.el
> framework, but only after the user explicitly says "please enable
> installation of Free, but non-FSF packages".  It would also make it
> easy to move a package into "main" once the paperwork was done by
> simply changing a few headers -- the rest of the package.el
> integration would already have been done and tested in the "non-fsf"
> repository.

I don't think that "non-fsf" is a good label: it focuses on a legal
aspect, not on the motivation behind it.  And it is irrelevant for the
end user whether or not a GPLed piece of software is copyrighted by
the FSF or someone else (unless she wants to negotiate a different
license, but that's quite unlikely with Emacs packages).

If one wanted to make such a distinction, it would likely be better to
use something like

http://elpa.gnu.org/core or http://elpa.gnu.org/gnu-packages

and

http://elpa.nongnu.org/contrib

and make clear that the core packages require formal approval that
will imply a copyright assignment as a rule.

-- 
David Kastrup

Re: CVS is the `released version'

[Richard Stallman]

    Would it be acceptable to have two repositories "main" and "non-fsf",
    both hosted on gnu.org, and only have the former enabled by default?

I don't think this would solve all the problems I'm concerned about.
If some people are going to use a repository of packages
that we can't install in Emacs, I don't see why it helps to
have that repository on an FSF machine.

    That way Free software packages that are NOT assigned to the FSF (such
    as paredit, which is declares itself to be in the Public Domain),

If a program has been explicitly placed in the public domain, we could
install it.  That is an acceptable alternative to assigning the
copyright.

Re: CVS is the `released version'

[David Kastrup]

"Ken Manheimer" <ken.manheimer@gmail.com> writes:

> i like the idea of an incremental release mechanism for emacs.  but
> it needs to be done right - i think xemacs network-based packages
> update system doesn't quite do it, though it might be a step in the
> right direction.

XEmacs' system does not cater for packages created outside of a
central packaging structure.  If we have a package system, it should
make it possible for third parties to provide packages without us
having to check our own versions of them: that's a scenario that is
just begging to result in bit rot and outdated packages.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: CVS is the `released version'

[Lukasz Stafiniak]

On 5/9/07, Robert J. Chassell <bob@rattlesnake.com> wrote:
> Remember, for many people, but not for many moderns, CVS provides the
> `released version' of GNU Emacs.  It is the prime version used by
> those who contribute.  It is not a binary that cannot be changed.
> Once in a while, development needs to be frozen while bugs are fixed.
>
> Since more and more people are coming to think of or are forced to use
> big numbered releases and eschew the daily releases, they view a delay
> between one big numbered release and another as bad.  But those who
> enjoy daily releases hardly notice.
>
Our Emacs
who art in CVS
hallowed be thy name
thy Release come
thy will be done
on earth as it is in CVS.

Re: CVS is the `released version'

[Davis Herring]

> Our Emacs
> who art in CVS
> hallowed be thy name
> thy Release come
> thy will be done
> on earth as it is in CVS.
Give us this day our context patch,
And forgive us our edits,
As we forgive our editors;
And lead us not into SIGSEGV,
But deliver us from vi:
For thine is the control, the super,
And the meta forever.
C-c C-c

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: CVS is the `released version'

[Thien-Thi Nguyen]

() "Davis Herring" <herring@lanl.gov>
() Thu, 10 May 2007 16:23:47 -0700 (PDT)

   > Our Emacs
   > who art in CVS
   > hallowed be thy name
   > thy Release come
   > thy will be done
   > on earth as it is in CVS.
   Give us this day our context patch,
   And forgive us our edits,
   As we forgive our editors;
   And lead us not into SIGSEGV,
   But deliver us from vi:
   For thine is the control, the super,
   And the meta forever.
   C-c C-c

   what is a release?
   two birds sharing point of view,
   yet avoiding crash!

thi