[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Question about packaging emacs 20.5a.

(This isn't a big deal, but I thought I'd see if anyone had a better
 idea before I make any substantial changes to the pacakge build

The recent 20.5 upstream source was packaged as emacs-20.5a.tar.gz,
but it unpacks and builds as emacs 20.5, so there are a couple of
"problems" with just releasing it as Debian version 20.5a-1:

  1) I'll have to use epochs to correct the version ordering when the
     "official" 20.5 is released since dpkg thinks 20.5a is newer than
     20.5.  (Epochs aren't a big deal to me, so if that's the best
     approach, then fine.)

  2) I'll have to change my build scripts.  Right now I assume that
     the upstream component of the Debian version (the 20.5a in
     20.5a-1) is the value that the executable will use in various
     places like in it's load-path.  That won't be true anymore.

I can't take the opposite tack and just name the Debian version 20.5,
because then when emacs-20.5.tar.gz is finally released upstream, the
upstream source tarfile will change contents even though the Debian
name for the upstream source file will stay the same


Right now, I'm leaning toward

  1) Use 20.5a-1 and epochs
  2) Use 20.4-pre20.5-a-1 and no epochs

In both cases I'll either have to modify my build scripts to be
smarter about picking out the important upstream version bits, or to
quit trying to do that automatically from the debian/changelog and
just type into the rules file by hand.  Not a big deal, but another
potential source of packaging errors.  Alternately, I could just
always use a Debian version like
parsing job trivial, but I'd prefer to keep the version similar to the
upstream one if possble.

Is there an easier solution I'm overlooking?

In any case, presuming that 20.5 has y2k fixes, I need to do something


Rob Browning <rlb@cs.utexas.edu> PGP=E80E0D04F521A094 532B97F5D64E3930

Reply to: