unofficial mirror of help-gnu-emacs@gnu.org
 help / color / mirror / Atom feed
From: ken <gebser@speakeasy.net>
Subject: Re: Is there an elisp package manager?
Date: Sun, 13 Aug 2006 13:01:01 -0400	[thread overview]
Message-ID: <44DF5ACD.7030102@speakeasy.net> (raw)
In-Reply-To: <87k65cd86g.fsf@comcast.net>

Robert D. Crawford wrote:
> ken <gebser@speakeasy.net> writes:
> 
>> I'll give a pitch for RPM.  There's been many a time when I've wanted to
>> upgrade emacs or elisp, but know that if I do, forever after I'll no
>> longer be able to use RPM for upgrades and I'll have to always upgrade
>> emacs and elisp manually.  So forget about enterprise environments.
> 
> Not all of us fall into those categories.  I use debian, so rpm is a bad
> solution, in this case anyway.  I would also stay away from apt in this
> case for the same reasons.  

It's true that not everyone falls into these categories.  In fact, I
don't think there's *any* category that *everyone* falls into.  That
shouldn't be a reason for not doing something, otherwise nothing would
ever get done.  It might be more fruitful to think in terms of that
well-worn aphorism, "the greatest good for the greatest number."




> Also, I am not, nor would I imagine are most
> users on this list, in an enterprise environment.  

Most of those who manage an enterprise environment pay for support from
the distro provider.  They don't need this list.  Moreover, it's often
the case that installing your own packages on an enterprise-provided
machine is not permitted.  So, yes, I'd guess you're probably correct on
this point.  But then are we talking about creating a package just for
the people on this list?  Don't think so.  Again, consider the greatest
good for the greatest number.

The distro provider sometimes develops its own RPMs, but I doubt that it
happens very often that they'll grab an emacs version from CVS and make
an RPM out of it, I imagine for purely practical reasons.  But if there
were an easier path from CVS to RPM, then they would.


> Furthermore, unless you are living on the bleeding edge of emacs
> development, it does not change that often.  It seems to me that most
> people would be able to live with an emacs installation for several
> years without the need to upgrade.

This must be a matter of personal assessment.  For reasons mentioned in
my previous post, I've resisted upgrading emacs three times in the past
year when not doing so adversely affected projects I was working on.  I
think I upgrade my entire OS more often than you (or whoever is meant by
"most people") upgrade your (their) emacs.  And I thought I was more
sluggish in upgrading than most people?!

Whatever the mean frequency of upgrade, the point of creating the app in
question is to make upgrading easier-- and "easier" should take into
account maintenance of the system as a whole.  Maybe it's necessary to
have been responsible for systems administration to relate to that.


> 
> While we are dreaming here, why don't we come up with a way to do a
> complete installation from this packaging system... emacs and all.  Make
> it so that it can sniff out the type of distro one uses and make the
> adjustments to the package database so that the system knows that there
> is a version of emacs/gnus/add-on-mode etc. installed.

I'm not dreaming at all.  Though you may have a different opinion, I
believe what I've proposed is quite reasonable.

And what you're talking about (dreaming of?) already exists in large
degree.  Suse has a package manager, a wrapper for RPM called YaST2 that
can perform both installs and upgrades, from CD or HD or from the net.
(This would be yet another reason for packaging emacs upgrades into RPMs.)


> 
> I have to say that if someone goes ahead with this, it should work like
> apt in that not only does it get the package and install it, it also
> grabs whatever dependencies are needed.

YaST2 does this.  It also works from the CLI or in a GUI.  It also
provides dynamic help text where options arise.  It also authenticates
packages prior to their installation, a definite requirement if security
is a concern at all.

(Suse also runs apt.)


> 
>> Standards aren't much use if there's a bazillion of them and they're all
>> incompatible with one another.  So why bother with an app that will see
>> limited use and, more than likely, will be replaced in a few years by
>> something far more practical?
> 
> Living by this logic, we would never get anything done as there is
> always something newer and better coming along.

Your statement reminds of one from Yogi Berra: "Nobody goes there
anymore.  It's too crowded."  :)

I guess to understand my statement, it's necessary to understand that
some innovations are better than others, that some are, quite literally,
"called for" because they are so practical and far-sighted, while other
innovations are more like short-term cludges and fade from use after a
short time.  IOW, not all innovations are equal.  Again, think "the
greatest good for the greatest number," where "number" can also mean
others coming along in the future.


> 
> rdc
> 

      reply	other threads:[~2006-08-13 17:01 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <mailman.5116.1155394815.9609.help-gnu-emacs@gnu.org>
2006-08-13  3:50 ` Are there an elisp package manager like apt-get or cpan? Þorne
2006-08-13  4:25   ` Þorne
2006-08-13  7:17     ` chylli
2006-08-13  7:06   ` Tim X
2006-08-13  7:58     ` chylli
2006-08-13  8:58     ` Tassilo Horn
2006-08-14  8:24       ` Tim X
2006-08-13 13:10   ` ken
     [not found]   ` <mailman.5139.1155474630.9609.help-gnu-emacs@gnu.org>
2006-08-13 14:25     ` Robert D. Crawford
2006-08-13 17:01       ` ken [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

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

  git send-email \
    --in-reply-to=44DF5ACD.7030102@speakeasy.net \
    --to=gebser@speakeasy.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).