2009/11/8 Jonathan Underwood <jonathan.underwood(a)gmail.com>:
2009/11/7 Jason L Tibbitts III <tibbs(a)math.uh.edu>:
>>>>>> "JU" == Jonathan Underwood
> JU> A new draft of the guidelines is here:
> JU> https://fedoraproject.org/wiki/PackagingDrafts/EmacsPackagingRevised
> These do look significantly simpler, which is generally a good thing.
> Is there a good way to see the actual diffs between this and the
> existing guidelines? Or could you summarize them in a bit more detail?
OK, I did diff the original and revised guidelines, but it's not that
easily digested, so I'll attempt a summary.
Some of the primary concerns with (x)emacs add on packages are:
1) Correct package and sub-package naming and organization
2) Installing the files in the right places
3) Ensuring that the version of (x)emacs that was used to byte compile
the elisp files is a requirement of the package - requiring build time
detection of the (x)emacs version
With the current guidelines, points 2 and 3 were handled by calling
pkg-config to define macros at add-on package build time. This makes
use of a pkg-config file installed with the (x)emacs package.
With the revised guidelines we make use of macros in the files
/etc/rpm/macros.[x]emacs to ensure the relevant macros are defined for
add-on package building. This removes the pkg-config complexity and
removes a lot of boilerplate from the spec files.
That's the main point of the guideline update.
At the same time I've reorganised the guidelines for clarity and
simplicity. I hope they're a lot easier to follow now.
Two extra points:
I should have emphasized that the changes to the guidelines are purely
about mechanism, and not policy. Nothing has changed with regard to
emacs add-on packaging policy in the guidelines.
I should also addd, as a sidenote, that the old pkg-config way of
doing things still works, as we haven't removed the pkg-config files
from the emacs/xemacs packages. So nothing breaks.