bug#14338: 24.3.50; ELPA package ack fails to install

bug#14338: 24.3.50; ELPA package ack fails to install

[chad]

Attempting to install the package `ack', I get:

  Debugger entered--Lisp error: (error "Error during download request: Not Found")
    signal(error ("Error during download request: Not Found"))
    error("Error during download request:%s" " Not Found")
    package-handle-response()
    package-download-tar(ack "1.1")
    package-download-transaction((ack))
    package-install(ack)
    mapc(package-install (ack))
    package-menu-execute()
    call-interactively(package-menu-execute nil nil)
    command-execute(package-menu-execute)

This problem has persisted over several days, at least.  To repeat from emacs -Q:

	M-x package-list-packages
	<navigate to `ack', version 1.1. It's the first package.>
	i
	x

I verified that other packages can be installed and upgraded, and
that ack can be neither installed nor upgraded (I first noticed it
when trying to upgrade, not with emacs -Q).

~Chad

	

bug#14338: 24.3.50; ELPA package ack fails to install

[Glenn Morris]

The package version is 1.01.
(version-to-list "1.01") -> (1 1)
Hence http://elpa.gnu.org/packages/archive-contents refers to version 1.1.
Hence it tries to download the non-existent 
http://elpa.gnu.org/packages/ack-1.1.tar
rather than
http://elpa.gnu.org/packages/ack-1.01.tar

For good measure,
http://elpa.gnu.org/packages/ack.html
thinks the latest version is 1.0 for some reason.

bug#14338: 24.3.50; ELPA package ack fails to install

[Leo Liu]

On 2013-05-03 15:49 +0800, Glenn Morris wrote:
> The package version is 1.01.
> (version-to-list "1.01") -> (1 1)
> Hence http://elpa.gnu.org/packages/archive-contents refers to version 1.1.
> Hence it tries to download the non-existent 
> http://elpa.gnu.org/packages/ack-1.1.tar
> rather than
> http://elpa.gnu.org/packages/ack-1.01.tar
>
> For good measure,
> http://elpa.gnu.org/packages/ack.html
> thinks the latest version is 1.0 for some reason.

What should be done here to get it in sync?

BTW, increment the version number is an annoyance. I wonder if people
feel the same way too?

Leo

bug#14338: 24.3.50; ELPA package ack fails to install

[Glenn Morris]

Leo Liu wrote:

> What should be done here to get it in sync?

Maybe use a version that is not zero padded.
Is 1.01 supposed to be the same as 1.1, or not?

> BTW, increment the version number is an annoyance. I wonder if people
> feel the same way too?

I have no opinion. The motivation is in packages/README:

    This cron job only creates a new package when the "version" (as
    specified in the foo-pkg.el or in the "Version:" header) of a
    package is modified. This means that you can safely work on the next
    version here without worrying about the unstable code making it to
    GNU ELPA, and simply update the "version" when you want to release
    the new code.

Seems sensible. Surely there needs to be some way to prevent every
change going live immediately?

bug#14338: 24.3.50; ELPA package ack fails to install

[Glenn Morris]

PS grep suggests same issue in sokoban.el.

bug#14338: 24.3.50; ELPA package ack fails to install

[Leo Liu]

On 2013-05-04 00:01 +0800, Glenn Morris wrote:
> Maybe use a version that is not zero padded.
> Is 1.01 supposed to be the same as 1.1, or not?

OK, I have bumped the version to 1.2.

On 2013-05-04 00:04 +0800, Glenn Morris wrote:
> PS grep suggests same issue in sokoban.el.

This version number was from XEmacs. I wonder if the archiver can be
more flexible. The versioning scheme isn't peculiar.

Leo

bug#14338: 24.3.50; ELPA package ack fails to install

[Glenn Morris]

Leo Liu wrote:

> I wonder if the archiver can be more flexible. The versioning scheme
> isn't peculiar.

If you want 1.01 (or 1.001 etc) to be different to 1.1 (do you? I don't
know), then I don't think that can be done without an incompatible
change to archive-contents.

But if 1.01 is the same as 1.1, that can probably be made to work.
But then why not just write 1.1.

bug#14338: 24.3.50; ELPA package ack fails to install

[Glenn Morris]

Leo Liu wrote:

>> PS grep suggests same issue in sokoban.el.
>
> This version number was from XEmacs. I wonder if the archiver can be
> more flexible. The versioning scheme isn't peculiar.

Actually, I see the sokoban-pkg.el file contains 1.0.4, so it probably
works. Clearly there is ambiguity in what "1.04" means. 1.4 or 1.0.4?

bug#14338: 24.3.50; ELPA package ack fails to install

[Leo Liu]

On 2013-05-05 02:56 +0800, Glenn Morris wrote:
> Actually, I see the sokoban-pkg.el file contains 1.0.4, so it probably
> works. Clearly there is ambiguity in what "1.04" means. 1.4 or 1.0.4?

I am glad it was written as 1.0.4 (might have been a typo of 1.04). I
suppose we have resolved all issues in this bug.

Leo

bug#14338: 24.3.50; ELPA package ack fails to install

[Glenn Morris]

Leo Liu wrote:

> On 2013-05-05 02:56 +0800, Glenn Morris wrote:
>> Actually, I see the sokoban-pkg.el file contains 1.0.4, so it probably
>> works. Clearly there is ambiguity in what "1.04" means. 1.4 or 1.0.4?
>
> I am glad it was written as 1.0.4 (might have been a typo of 1.04). I
> suppose we have resolved all issues in this bug.

I'm not trying to difficult, but I really would like to know what this
version scheme means. Could you explain it? Is 1.01 the same as 1.1,
just written differently for sorting purposes? (IIUC, you added both ack
and sokoban.)

bug#14338: 24.3.50; ELPA package ack fails to install

[Leo Liu]

On 2013-05-06 08:20 +0800, Glenn Morris wrote:
> I'm not trying to difficult, but I really would like to know what this
> version scheme means. Could you explain it? Is 1.01 the same as 1.1,
> just written differently for sorting purposes? (IIUC, you added both ack
> and sokoban.)

It was supposed to mean 1.1 but padded with 0. I was thinking 1.9 is
written as 1.09 and it is clearly smaller than 1.10 etc. But 1.04 was
the number used by xemacs and I have no idea why it was picked up.

Leo