* bug#11410: 24.1.50; package.el `emacs' package information is broken
@ 2012-05-05 11:24 Toby Cubitt
2012-05-05 12:37 ` Stefan Monnier
0 siblings, 1 reply; 6+ messages in thread
From: Toby Cubitt @ 2012-05-05 11:24 UTC (permalink / raw)
To: 11410
The Elisp manual "Conventional Headers for Emacs Libraries" node says:
The package code automatically defines a package named `emacs'
with the version number of the currently running Emacs. This can
be used to require a minimal version of Emacs for a package.
However, the version number for the `emacs' package is null in my Emacs
build (a very recent bzr checkout), and the package description for the
`emacs' package reads "abbrev mode commands for Emacs"!?!
Here's the package description displayed by package.el:
emacs is a built-in package.
Status: Built-in.
Summary: abbrev mode commands for Emacs
And here's the relevant element of `package--builtins' from my
finder-inf.el:
(emacs . [nil nil "abbrev mode commands for Emacs"])
This breaks installation of any ELPA packages that depend on a minimum
Emacs version.
Toby
In GNU Emacs 24.1.50.1 (i686-pc-linux-gnu, GTK+ Version 2.24.10)
of 2012-05-03 on c3po
Windowing system distributor `The X.Org Foundation', version 11.0.11102000
Configured using:
`configure '--prefix=/usr' '--host=i686-pc-linux-gnu'
'--mandir=/usr/share/man' '--infodir=/usr/share/info'
'--datadir=/usr/share' '--sysconfdir=/etc' '--localstatedir=/var/lib'
'--disable-dependency-tracking' '--program-suffix=-emacs-24'
'--infodir=/usr/share/info/emacs-24'
'--enable-locallisppath=/etc/emacs:/usr/share/emacs/site-lisp'
'--with-crt-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.5.3/../../../../lib'
'--with-gameuser=games' '--without-compress-info'
'--disable-maintainer-mode' '--without-hesiod' '--without-kerberos'
'--without-kerberos5' '--with-gpm' '--with-dbus' '--without-gnutls'
'--without-xml2' '--without-selinux' '--without-sound' '--with-x'
'--without-ns' '--without-gconf' '--without-gsettings'
'--with-toolkit-scroll-bars' '--without-wide-int' '--without-gif'
'--without-jpeg' '--with-png' '--with-rsvg' '--without-tiff'
'--with-xpm' '--without-imagemagick' '--with-xft' '--without-libotf'
'--without-m17n-flt' '--with-x-toolkit=gtk' 'EBZR_BRANCH=trunk'
'EBZR_REVNO=108111' '--build=i686-pc-linux-gnu'
'build_alias=i686-pc-linux-gnu' 'host_alias=i686-pc-linux-gnu'
'CFLAGS=-march=prescott -O2 -pipe -O2' 'LDFLAGS=-Wl,-O1
-Wl,--as-needed' 'CPPFLAGS=''
Important settings:
value of $LC_ALL: nil
value of $LC_COLLATE: nil
value of $LC_CTYPE: nil
value of $LC_MESSAGES: nil
value of $LC_MONETARY: nil
value of $LC_NUMERIC: nil
value of $LC_TIME: nil
value of $LANG: en_GB.utf-8
value of $XMODIFIERS: nil
locale-coding-system: utf-8-unix
default enable-multibyte-characters: t
--
Dr T. S. Cubitt
Mathematics and Quantum Information group
Department of Mathematics
Complutense University
Madrid, Spain
email: tsc25@cantab.net
web: www.dr-qubit.org
^ permalink raw reply [flat|nested] 6+ messages in thread* bug#11410: 24.1.50; package.el `emacs' package information is broken
2012-05-05 11:24 bug#11410: 24.1.50; package.el `emacs' package information is broken Toby Cubitt
@ 2012-05-05 12:37 ` Stefan Monnier
2012-05-05 12:52 ` Toby Cubitt
0 siblings, 1 reply; 6+ messages in thread
From: Stefan Monnier @ 2012-05-05 12:37 UTC (permalink / raw)
To: Toby Cubitt; +Cc: 11410
> The Elisp manual "Conventional Headers for Emacs Libraries" node says:
> The package code automatically defines a package named `emacs'
> with the version number of the currently running Emacs. This can
> be used to require a minimal version of Emacs for a package.
BTW I highly doubt the usefulness of such a dependency. Package.el can
use dependencies to automatically download&update needed packages, but
it currently can't do that for `emacs', and in general it's can't do
that at all (the same set of installed packages might even be used by
different versions of Emacs).
So such a dependency makes more sense as a load-time test (written in
Elisp directly in the package's code) rather than as
a package.el dependency.
Stefan
^ permalink raw reply [flat|nested] 6+ messages in thread* bug#11410: 24.1.50; package.el `emacs' package information is broken
2012-05-05 12:37 ` Stefan Monnier
@ 2012-05-05 12:52 ` Toby Cubitt
2012-05-05 13:23 ` Stefan Monnier
0 siblings, 1 reply; 6+ messages in thread
From: Toby Cubitt @ 2012-05-05 12:52 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 11410
On Sat, May 05, 2012 at 08:37:14AM -0400, Stefan Monnier wrote:
> > The Elisp manual "Conventional Headers for Emacs Libraries" node says:
> > The package code automatically defines a package named `emacs'
> > with the version number of the currently running Emacs. This can
> > be used to require a minimal version of Emacs for a package.
>
> BTW I highly doubt the usefulness of such a dependency. Package.el can
> use dependencies to automatically download&update needed packages, but
> it currently can't do that for `emacs', and in general it's can't do
> that at all (the same set of installed packages might even be used by
> different versions of Emacs).
>
> So such a dependency makes more sense as a load-time test (written in
> Elisp directly in the package's code) rather than as
> a package.el dependency.
Surely the idea is for packages to refuse to even *install* under Emacs
versions where they won't work (package.el displays an "emacs x.x not
available" in this case.)
As I understand it, with a load-time test package.el will still downland
and install the package successfully, even though the package won't
work. With the `emacs' version dependency, install will instead fail with
an informative message.
That seems like a useful feature to me.
(Even more useful when the package in question is actually being
installed as part of a chain of dependencies.)
Toby
--
Dr T. S. Cubitt
Mathematics and Quantum Information group
Department of Mathematics
Complutense University
Madrid, Spain
email: tsc25@cantab.net
web: www.dr-qubit.org
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#11410: 24.1.50; package.el `emacs' package information is broken
2012-05-05 12:52 ` Toby Cubitt
@ 2012-05-05 13:23 ` Stefan Monnier
2012-05-05 14:51 ` Toby Cubitt
2012-05-06 4:06 ` Chong Yidong
0 siblings, 2 replies; 6+ messages in thread
From: Stefan Monnier @ 2012-05-05 13:23 UTC (permalink / raw)
To: Toby Cubitt; +Cc: 11410
> Surely the idea is for packages to refuse to even *install* under Emacs
> versions where they won't work (package.el displays an "emacs x.x not
> available" in this case.)
[...]
> That seems like a useful feature to me.
Preventing users to do what they want doesn't sound useful to me (as
I was recently reminded when gparted obnoxiously refused to work on my
USB stick, arguing that I need to be root to use it, even though I had
write-access to it, and then when I tried again as root it again refused
obnoxiously to move the partition arguing that it doesn't know the
file-system type (of course, in 99% of the cases moving a partition can
be done without paying any attention to the partition type)). Note that
I reported such problems to gparted already years ago. Hell, even
"gparted --help" complains if you're not root. Next thing you know,
they'll change the access permissions to the gparted manpage so only
root can read it.
I guess a warning could be useful, yes.
Stefan
^ permalink raw reply [flat|nested] 6+ messages in thread* bug#11410: 24.1.50; package.el `emacs' package information is broken
2012-05-05 13:23 ` Stefan Monnier
@ 2012-05-05 14:51 ` Toby Cubitt
2012-05-06 4:06 ` Chong Yidong
1 sibling, 0 replies; 6+ messages in thread
From: Toby Cubitt @ 2012-05-05 14:51 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 11410
On Sat, May 05, 2012 at 09:23:16AM -0400, Stefan Monnier wrote:
> > Surely the idea is for packages to refuse to even *install* under Emacs
> > versions where they won't work (package.el displays an "emacs x.x not
> > available" in this case.)
> [...]
> > That seems like a useful feature to me.
>
> Preventing users to do what they want doesn't sound useful to me (as
> I was recently reminded when gparted obnoxiously refused to work on my
> USB stick, arguing that I need to be root to use it, even though I had
> write-access to it,
[...]
Sure, I share your annoyance with bogus refusals to run. (The number of
sudoer entries I have just to work-around this kind of annoyance is
steadily growing).
But I don't think this is analogous. Package.el already prevents users
from installing a package if dependencies can't be met. Why should an
emacs version dependency behave any differently?
This sounds to me more like a good argument for adding a "force" option
to `package-install', to make it ignore dependency failures. (Most
package managers have an option like this, usually with a scary warning
about potential breakage.)
Toby
PS: I'm not actually using emacs version dependencies any more. After
discovering this breakage, I decided they were superfluous anyway in my
case. Nonetheless, either this bug needs fixing, or the `emacs' virtual
package needs to be removed entirely and the Elisp manual updated.
--
Dr T. S. Cubitt
Mathematics and Quantum Information group
Department of Mathematics
Complutense University
Madrid, Spain
email: tsc25@cantab.net
web: www.dr-qubit.org
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#11410: 24.1.50; package.el `emacs' package information is broken
2012-05-05 13:23 ` Stefan Monnier
2012-05-05 14:51 ` Toby Cubitt
@ 2012-05-06 4:06 ` Chong Yidong
1 sibling, 0 replies; 6+ messages in thread
From: Chong Yidong @ 2012-05-06 4:06 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 11410
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> Surely the idea is for packages to refuse to even *install* under Emacs
>> versions where they won't work (package.el displays an "emacs x.x not
>> available" in this case.)
> [...]
>> That seems like a useful feature to me.
>
> Preventing users to do what they want doesn't sound useful to me
All the same, previous versions of package.el did handle the `emacs'
package, and the current version not doing so is a bug. I've committed
a fix to trunk.
I agree that there should be an easy way to tell the package manager to
ignore package dependencies, but such a mechanism should apply to all
packages and not just the `emacs' package.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2012-05-06 4:06 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-05-05 11:24 bug#11410: 24.1.50; package.el `emacs' package information is broken Toby Cubitt
2012-05-05 12:37 ` Stefan Monnier
2012-05-05 12:52 ` Toby Cubitt
2012-05-05 13:23 ` Stefan Monnier
2012-05-05 14:51 ` Toby Cubitt
2012-05-06 4:06 ` Chong Yidong
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.