GNU bug report logs - #11410
24.1.50; package.el `emacs' package information is broken

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 11410 in the body.
You can then email your comments to 11410 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Toby Cubitt <tsc25 <at> cantab.net>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.1.50; package.el `emacs' package information is broken
Date: Sat, 5 May 2012 13:24:24 +0200

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 <at> cantab.net
web:   www.dr-qubit.org

Message #8 received at 11410 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Toby Cubitt <toby-dated-1337426689.98a5fb <at> dr-qubit.org>
Cc: 11410 <at> debbugs.gnu.org
Subject: Re: bug#11410: 24.1.50;
	package.el `emacs' package information is broken
Date: Sat, 05 May 2012 08:37:14 -0400

> 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

Message #11 received at 11410 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Toby Cubitt <tsc25 <at> cantab.net>
Cc: 11410 <at> debbugs.gnu.org
Subject: Re: bug#11410: 24.1.50;
	package.el `emacs' package information is broken
Date: Sat, 05 May 2012 09:23:16 -0400

> 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

Message #14 received at 11410 <at> debbugs.gnu.org (full text, mbox):

From: Toby Cubitt <toby-dated-1337439139.52ea2f <at> dr-qubit.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 11410 <at> debbugs.gnu.org
Subject: Re: bug#11410: 24.1.50; package.el `emacs' package information is
	broken
Date: Sat, 5 May 2012 16:51:54 +0200

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 <at> cantab.net
web:   www.dr-qubit.org

Message #17 received at 11410 <at> debbugs.gnu.org (full text, mbox):

From: Toby Cubitt <toby-dated-1337431993.e7ada9 <at> dr-qubit.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 11410 <at> debbugs.gnu.org
Subject: Re: bug#11410: 24.1.50; package.el `emacs' package information is
	broken
Date: Sat, 5 May 2012 14:52:45 +0200

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 <at> cantab.net
web:   www.dr-qubit.org

Message #20 received at 11410 <at> debbugs.gnu.org (full text, mbox):

From: Chong Yidong <cyd <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 11410 <at> debbugs.gnu.org, Toby Cubitt <tsc25 <at> cantab.net>
Subject: Re: bug#11410: 24.1.50;
	package.el `emacs' package information is broken
Date: Sun, 06 May 2012 12:06:37 +0800

Stefan Monnier <monnier <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.