Re: Call for testing: Daily snapshot builds of Emacs for Ubuntu

[Robert Park]

On Mon, May 13, 2013 at 2:08 AM, Julien Danjou <address@hidden> wrote:
> On Sun, May 12 2013, Robert Park wrote:
>> You may be familiar with the snapshot packaging work done by Damien
>> Cassou; however his method is largely to build by hand once every
>> couple weeks, I am using Launchpad recipes to achieve the same thing
>> every day, in an entirely automated fashion.
>
> As far as I know, Damien used the packaging I maintain at:
>
>    http://anonscm.debian.org/gitweb/?p=users/acid/emacs-snapshot.git;a=summary

What's this then? Is this a debian package dedicated to emacs
snapshots? I honestly wasn't aware of this branch at all; I'd been
referring to the packaging for emacs24 that ubuntu imports from
debian.

>> To achieve this, I have written all new packaging metadata from
>> scratch, discarding many years of legacy cruft from the debian build
>> system (where the debian packaging weighs in at 4900 lines of code, I
>> have nearly achieved feature parity with only 1495 lines of code).
>
> Ok, this claim makes me smile. The actual Debian packaging is not 4900
> lines. Sure, the files in debian/ are around that number of lines… with
> a ChangeLog files of 3325. There isn't that much code at all, even the
> debian/rules file is only 400 SLOC long.

Hmmm, nope. The debian/rules that I've been referring to is 629 lines
(compared to 166 for mine). So it seems we are talking about different
things ;-)

Admittedly I did come up with that original figure by doing a
quickndirty 'find|xargs wc -l' and it did include the changelog,
there's still a lot of cruft that I am rebelling against. Like 800
lines worth of distropatching just to rip out some GFDL stuff. I find
that kind of thing quite odious and pride myself on having a packaging
branch that has no distropatches at all ;-)

> That said, what's the reason for you not to try to improve the already
> existing and working code?

One of my major goals was Upstream Purity, so that people testing the
packages would be having an unadulterated trunk experience, hopefully
making bug reports more relevant and timely. Both the packaging branch
that you've linked and the one I've been referring to for emacs24
contain a huge load of distropatches.

Now, I'm not opposed to porting some of the work I've done to improve
the existing packages, just that on the whole I was a bit overwhelmed
by the size of the existing packages and wanted to make something
leaner. I'm quite pleased with what I've achieved and I'm using it
every day, I uninstalled emacs24 package over a month ago and haven't
looked back ;-)