help-gnu-emacs
[Top][All Lists]
Advanced

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

Re: Is there an elisp package manager?


From: ken
Subject: Re: Is there an elisp package manager?
Date: Sun, 13 Aug 2006 13:01:01 -0400
User-agent: Thunderbird 1.5.0.5 (X11/20060725)

Robert D. Crawford wrote:
> ken <address@hidden> 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 via email to

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