Re: feature/package-vc has been merged

[Stefan Monnier]

> The side effect of that process is that there's no standartized way for
> these packages to require native modules is that building those packages
> in build systems isn't standartized, these packages have to be convinced
> to not build binaries while Emacs run but take the prebuild binaries
> from the package manager.

I'm not completely sure I understand to what you're alluding, but indeed
it causes extra work for things like Debian where they would benefit
from having a standard way to build (and locate) the extra artifacts
like the module of `pdf-tools`.

Currently packages like `pdf-tools` and `libpq` are fairly unusual but
I'd encourage the development of a standardized way to handle them.
Then Debian packagers would be able to take advantage of it.

>> I'm hoping that we'll develop a "standard" way to do it in the form of
>> some ELisp function/macro so that `pdf-tools`, `libpq`, etc... can
>> simply include a line or two of ELisp code which says how to compile
>> their artifact (possibly just running `make`, or `ninja`, ...).
> I'm not sure if that is always the best solution,

But that's what we can get fairly easily without disruption :-)

> maybe Melpa isn't the best place such packages.

Not sure what Melpa has to do with this, but if you mean the whole of
the ELPA infrastructure, then I think this is largely irrelevant: ELPA
is popular and users do want to install `pdf-tools` via `M-x
package-install`, so while there may be a better solution, we still need
to solve this problem.

> But just don't run them inside Emacs itself and not synchronously.

I lost you here.  I have no idea what "them" refers to.


        Stefan