GNU ELPA and package.el (was: Tramp as ELPA package)

[Stefan Monnier <monnier@iro.umontreal.ca>]

[ Changing title since it's not specific to Tramp.  ]

>>> Would it be possible to go the same line as org-mode has done?
>> I want to get rid of this Org hack, so I'm really not looking forward to
>> adding more such exceptions.
> As discussed before: The package requirements are too limiting to allow
> larger packages that need to have something built or generated (or even
> multiple autoload files) and it's not just Org that falls into this
> category.

I'm fully aware of that.  But you can push the prebuilt packages to
elpa.it rather than pushing them to some third-party distribution site,
and let elpa.gnu.org build the corresponding tarball.  This is the only
thing needed to eliminate the "Org hack".

This said, I'd love to get some help improving the elpa.gnu.org build
scripts so we can lift those restrictions altogether.
[ Basically, I'd like to be able to run those package-provided extra
  build rules in some kind of sandbox, e.g. an LXC container; but given
  the limited resources of elpa.gnu.org and its maintenance, it should
  ideally re-use the Debian install already provided by elpa.gnu.org.  ]

> The other unsolved problem is that anything that gets built in to Emacs
> releases still can't be later cleanly updated as a package because none
> of the "built-in packages" are actually packages in the ELPA sense.

I don't know what problem you're thinking of.
You can definitely upgrade Org, python.el, and several others.
I can imagine scenarios where it can partly break, but most of them seem
contrived to me, so if you know of practical problems, please let
me know.

> Last but not least I'll mention again that even if the two points above
> were solved, there still is not mechanism to cleanly separate packages
> installed at the system level (either with the Emacs release or
> separately by the admin) and user-level packages.  Specifically, if
> packages are installed at the system level, the user can either use them
> all or none of them, but can't really chose on a per-package basis
> (without jumping through a number of burning hoops, that is).

Currently, this choice is made via package-load-list.  That was the
initial way to do that, and there hasn't been much noise about it since,
so it hasn't seen much activity, but we could make it more flexible
if needed.  How do you imagine the user making this choice?
You mean you'd like to have a "clickable UI" or something else?

>> What you can do is create a Tramp package on elpa.git and push releases
>> there (complete with the pre-built auxiliary files).
> Well, that'd be more or less the same hack as you use for Org, except
> you use Git instead of an archive file.

That's a big difference for the build scripts.

>> This is what AUCTeX does, basically (where the files that would
>> ideally be auto-generated during packaging are instead stored in the
>> elpa.git repository after making them manually).
> That is a mistake and should not be forced on anyone.

I don't consider it a feature, but other than complaints, I haven't
gotten much help in trying to improve the situation.


        Stefan