Dear All,
We've recently added some macro definitions under /etc/rpm/macros.[x]emacs to simplify add on packaging for (X)Emacs. The main point being that we no longer use the pkg-config way of finding directory locations etc at add-on package build time, which removes all the boiler plate stufff that was being added to every add on package. A new draft of the guidelines is here:
https://fedoraproject.org/wiki/PackagingDrafts/EmacsPackagingRevised
Comments welcome!
Best wishes, Jonathan
"JU" == Jonathan Underwood jonathan.underwood@gmail.com writes:
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?
Also, I think you might as well go ahead and remove BuildRoot: and the first line after %install from the templates, since they're not required in any supported Fedora release at this point.
- J<
2009/11/7 Jason L Tibbitts III tibbs@math.uh.edu:
"JU" == Jonathan Underwood jonathan.underwood@gmail.com writes:
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.
Also, I think you might as well go ahead and remove BuildRoot: and the first line after %install from the templates, since they're not required in any supported Fedora release at this point.
OK, thanks, have done that.
Cheers, Jonathan
2009/11/8 Jonathan Underwood jonathan.underwood@gmail.com:
2009/11/7 Jason L Tibbitts III tibbs@math.uh.edu:
> "JU" == Jonathan Underwood jonathan.underwood@gmail.com writes:
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:
- Correct package and sub-package naming and organization
- Installing the files in the right places
- 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.
J.
Dear FPC,
OK - since there seems to have been no issues with the revised guidelines raised, I've changed the entry in the PackagingDraftsTodo table to "Ratify" - hopefully this can be voted on at the next FPC meeting.
Incidentally, I looked for the committee minutes for recent FPC meetings, and the latest available ones are 09/09 - has the FPC stopped meeting, or is it just the the minutes haven't been posted?
Cheers, Jonathan
"JU" == Jonathan Underwood jonathan.underwood@gmail.com writes:
JU> Dear FPC, OK - since there seems to have been no issues with the JU> revised guidelines raised, I've changed the entry in the JU> PackagingDraftsTodo table to "Ratify" - hopefully this can be voted JU> on at the next FPC meeting.
That's putting the cart before the horse. We use ratify to indicate that the guidelines have been approved by FPC and are to be ratified by FESCo.
- J<
2009/11/14 Jason L Tibbitts III tibbs@math.uh.edu:
"JU" == Jonathan Underwood jonathan.underwood@gmail.com writes:
JU> Dear FPC, OK - since there seems to have been no issues with the JU> revised guidelines raised, I've changed the entry in the JU> PackagingDraftsTodo table to "Ratify" - hopefully this can be voted JU> on at the next FPC meeting.
That's putting the cart before the horse. We use ratify to indicate that the guidelines have been approved by FPC and are to be ratified by FESCo.
Oops, sorry. I;ve changed it to "Next meeting"
On Sat, Nov 14, 2009 at 01:40:41PM +0000, Jonathan Underwood wrote:
Incidentally, I looked for the committee minutes for recent FPC meetings, and the latest available ones are 09/09 - has the FPC stopped meeting, or is it just the the minutes haven't been posted?
We haven't been meeting -- I think it's because we finally got through all of the pending Guideline changes. But with this on the docket, we'll need to get together again :-)
-Toshio
2009/11/17 Toshio Kuratomi a.badger@gmail.com:
On Sat, Nov 14, 2009 at 01:40:41PM +0000, Jonathan Underwood wrote:
Incidentally, I looked for the committee minutes for recent FPC meetings, and the latest available ones are 09/09 - has the FPC stopped meeting, or is it just the the minutes haven't been posted?
We haven't been meeting -- I think it's because we finally got through all of the pending Guideline changes. But with this on the docket, we'll need to get together again :-)
Ok, that's good to hear, thanks for clarifying. Incidentally, I notice the DraftsTodo table has two drafts labelled as "Next Meeting" and 4 others as "Discuss" so it's possible that a bit of a backlog has built up (or the table is out of date).
J.
Hi,
Since the FPC and FESCO have approved the updated emacs add-on packaging guidelines[1] can someone move the new guidelines to
https://fedoraproject.org/wiki/Packaging:Emacs
Thanks, Jonathan
[1] http://meetbot.fedoraproject.org/fedora-meeting/2009-12-04/fesco.2009-12-04-...
packaging@lists.fedoraproject.org
-
Jason L Tibbitts III -
Jonathan Underwood -
Toshio Kuratomi