Put updated package.el in ELPA? (and cl-lib backport)

[Daniel Hackney <dan@haxney.org>]

Yeah, yeah, I'm obsessed with package.el. So sue me ;)

Since my branch of package.el wasn't ready in time for 24.3, I'd like to
distribute it via ELPA itself. This would let us develop new features
(like Org-based READMEs) and make them available to people without
having to wait for 24.4. Obviously, this is a big deal and, if not done
carefully, could break a lot of people's installations. Real care and
frequent testing would be needed to ensure a smooth rollout. Any changes
to "archive-contents" or "FOO-pkg.el" files would need to be backward-
and forward-compatible. Luckily, the current package.el is perfectly
fine with extra elements in "FOO-pkg.el" files as well as
"archive-contents".

Is this something you all think would be appropriate?

On a related note, my branch of package.el relies on `cl-lib' from 24.3.
It would be impractical to maintain two versions, one using
`cl-defstruct' and the other using `defstruct'. Since people should be
migrating towards `cl-lib' in general, this presents a problem: either
use `cl' and get byte compiler warning or use `cl-lib' and restrict your
audience to 24.3 users.

I propose an ELPA-installable package called `cl-lib' which would be
like 24.3's `cl', but in reverse. It would consist of a bunch of aliases
to the `cl' functions and macros so that authors on <= 24.2 could use
`cl-*' functions without excluding everyone not on 24.3.

Once someone upgrades to 24.3, they should be transitioned to the
built-in `cl-lib'. This could be done by setting the version number of
the ELPA `cl-lib' to be lower than the built-in version in 24.3 so that
when package.el is activating packages, it would see that there is a
newer version of `cl-lib' already loaded and skip the ELPA-based
`cl-lib'.

Thoughts?

--
Daniel Hackney