Use ELPA for distribution?

[Reuben Thomas]

I just managed to use web-vcs-nxhtml, which is nice.

However, it's a rather odd interface: it asks me to look at each file I download, and then presents a huge build log. I understand that here I am installing developer sources, not a finished package, but I still am unlikely to have the time and expertise to manually review the code I'm installing; basically, I'm prepared to trust the author.

Hence, how about something a bit simpler: instead of a custom installation interface, why not just have a custom installation source for ELPA, so users can use a standard interface to update nXhtml? (ELPA is going to be included in Emacs 24.)

[lborgman (lennart-borgman)]

Hi Thomas (is that your last or first name?), I am glad you got it working. What did you do?

There is a possibility to review each file, but you do not have to do that. There are several choices and one is to just download the files without stopping.

This downloading works by intercepting (require ...):

- If the library is not found on the pc
- AND it is marked as accessible in the nXhtml repository
- AND you have somehow said it is ok to download it (there are several ways to say this)

THEN it will be downloaded and installed on your pc.

I added the possibility to review downloaded files before installing them because Richard Stallman thought that just downloading them the way I do there would be unsafe.

My intention for writing this would that this mechanism would be included in Emacs to support ELPA. But there is a long way to go before that will happen, I think. The code is mostly ready, but it will have to be discussed and accepted to.

nXhtml is thought to be included in ELPA. I have given Chong permissions to just transfer it as he likes. But there will be some trouble during this process to keep things synced. Help is welcome.

[Reuben Thomas (rrt)]

On 13 April 2011 21:22, lborgman <email address hidden> wrote:
> Hi Thomas (is that your last or first name?)

Hi, because it is perhaps not obvious that I am English, a lot of
Western Europeans guess this wrong! I am in fact Reuben.

> I am glad you got it working. What did you do?

I just followed the instructions on the Wiki, as you told me. (By the
way, it's a bit confusing that there is some important material on the
Wiki, rather than the main web pages. Can I fix this too, and move the
main material to the nXhtml web pages only? The Emacs Wiki is more a
place for Emacs users to make notes before the upstream maintainer for
a package has a chance to add features/fix bugs.)

> There is a possibility to review each file, but you do not have to do
> that. There are several choices and one is to just download the files
> without stopping.

Right, I didn't spot that.

> I added the possibility to review downloaded files before installing
> them because Richard Stallman thought that just downloading them the way
> I do there would be unsafe.

He's right it's unsafe, but it's not practical to review each file you
download. ELPA does not try to do this. A sensible mechanism relies on
signing, like most Linux distributions. For now, I would concentrate
on getting nXhtml into ELPA.

> nXhtml is thought to be included in ELPA. I have given Chong permissions
> to just transfer it as he likes. But there will be some trouble during
> this process to keep things synced. Help is welcome.

There is no problem, you just send new versions to Tom Tromey,
although he can be a bit slow to update. For this reason, and also in
order to provide regular development updates, it should be possible to
provide a third-party ELPA download source, but again, this is not
urgent; you can use web-vcs-nxhtml for now.

There is very little work to do to make a package ready for ELPA; I
did it myself for lua-mode. See here:

http://tromey.com/elpa/upload.html

If you would like help from me with this, then let me know if there's
anything special I should do before starting a branch.

--
http://rrt.sc3d.org

[lborgman (lennart-borgman)]

Hi Reuben, ;-)
Yes, please move that material to the web pages. That was actually my plan after introducing it on the wiki first and letting it stabilize so to say there. Could you please just download the .html files and change them for now and mail them to me so I can upload them?

Does not the signing mechanism depend on that there has already been a review of the files? I am not sure that is very good by itself in this case. I think it safer to give an easy way for preview (which I offer here, it could be enhanced by for example offer preview after downloading of all files, but before install).

Maybe it is ok to keep nXhtml as one monolithic package for now, but later it should be split (and that gives me some headache, practically).

Why do you need to start a new branch for the ELPA upload?

[Reuben Thomas (rrt)]

On 14 April 2011 01:31, lborgman <email address hidden> wrote:
> Does not the signing mechanism depend on that there has already been a
> review of the files?

No, the point of signing is that you have someone to blame if things
go wrong, i.e. an audit trail. How much code in Debian or Ubuntu do
you think has actually been read by the maintainer who signs the
package upload to the archive?

And I repeat, users are not going to read the code. Heck, even I don't
read the code, though I know the potential dangers, because I simply
don't have time. So any procedure which offers to let users read the
code just looks silly and annoying, and wastes users' time, just like
click-through EULAs which no-one reads.

And signing does not necessarily mean cryptographic signing. In ELPA,
for example, the source packages have all come from identifiable
sources, even though the mechanisms are informal. Cryptographic
signing just makes it more certain and formalizes the procedure.

> Maybe it is ok to keep nXhtml as one monolithic package for now, but
> later it should be split (and that gives me some headache, practically).

Right.

> Why do you need to start a new branch for the ELPA upload?

Because I will need to make some small code changes, which you will
need to merge? I don't mean that the branch has to be publically
visible, I just meant a private branch on my machine.

[lborgman (lennart-borgman)]

I see. So how do you do to sign the code cryptographically? Can bzr help with that?

So you say you need a new branch. What do you want me to do? I do not know much about branches.

[Reuben Thomas (rrt)]

On 14 April 2011 17:54, lborgman <email address hidden> wrote:
> I see. So how do you do to sign the code cryptographically? Can bzr help
> with that?

Normally with gpg.

This whole topic is not really one you should need to worry about: use
existing mechanisms to distribute your code, whether checkout from VCS
repo, or packaging in ELPA or Linux distros.

> So you say you need a new branch. What do you want me to do? I do not
> know much about branches.

I don't think I need you to do anything.

--
http://rrt.sc3d.org

[Daniel Hackney (haxney)]

I'm curious about the state of this bug. Has there been progress on it? Either way, I'd like to help to achieve this goal, though help from Reuben would be most welcome.

On the topic of how to progress, I think the first task should be to spin off as many of the files within the nXhtml package as possible. Many of them, like `php-mode', can easily be put into their own, self-contained package. As I understand it, there are some changes to various libraries not yet merged into their upstreams (`php-mode' being one of the main ones, complicated by the fact that it doesn't really seem to have much of an "upstream"). Everything in the "related" directory could be broken out into individual packages and perhaps merged with their upstreams. At any rate, they can be their own entities with their own release schedule and version numbers. Probably the same with everything in "util" as well.

In fact, you could probably break most or all of nXhtml up into separate, individual packages which users could download separately and which could be maintained individually, with "nxhtml" being a meta-package which depends on all of the files in the repo now.

Getting ahead of myself. Let me know if any progress has been made on ELPA-izing nXhtml, and I'll hook onto that or just fork the "emacsmirror/nxhtml" repo on github and start on it myself.

[Reuben Thomas (rrt)]

I'm sorry, I won't help myself as I've given up trying to use nXhtml, but I agree completely with your approach: the great thing is that even if you don't finish it, packaging up some of nXhtml's dependencies will be beneficial in itself.