Dear Packaging Committee,
I have placed a draft Guidelines document on the wiki for your consideration. This document covers the packaging of Emacs and XEmacs add-on packages, and provides two template spec files with the intention of lowering the inertial barrier to developing packages for (X)Emacs. The doc can be found here:
http://fedoraproject.org/wiki/PackagingDrafts/EmacsenAddOns
And I have added it to the table here:
http://fedoraproject.org/wiki/PackagingDrafts/DraftsTodo
This document doesn't attempt to change guidelines in any way, but rather clarify the situation as presented in the Package Naming Guidelines, and codify them in the form of spec templates.
Comments gladly received!
Best wishes, Jonathan
On Monday 07 May 2007, Jonathan Underwood wrote:
Dear Packaging Committee,
I have placed a draft Guidelines document on the wiki for your consideration. This document covers the packaging of Emacs and XEmacs add-on packages, and provides two template spec files with the intention of lowering the inertial barrier to developing packages for (X)Emacs.
Thanks.
Comments gladly received!
Quickly reading through it, here's a couple.
1) I think cases where install time dependencies on plain "emacs" or "xemacs" are desirable are very rare. The usual problem with those is that they bind the add-on packages to the corresponding full featured variants, ie. ones built with X etc, so one can't use them with only the -nox variant installed. That's why I addded a virtual "xemacs(bin)" Provides to the xemacs and xemacs-nox packages - that'd be a better thing to have a dependency on than eg. "xemacs" unless the full featured GUI version is specifically required. The emacs packages don't have that functionality (yet?), so I think the best thing for them for now would be to have a dependency on emacs-common instead of emacs or emacs-nox.
2) At least in the XEmacs case, the dependency on xemacs(bin) should be versioned, like "Requires: xemacs(bin) >= $evr_of_xemacs_used_to_build_the_package". The xemacs-bytecompiled *.elc files are in the vast majority of cases forwards compatible, but much less often backwards compatible. See the xemacs-packages-base and xemacs-packages-extras packages for examples. (Hm, I see those have deps on xemacs-common instead of xemacs(bin), will have a look.)
On 07/05/07, Ville Skyttä ville.skytta@iki.fi wrote:
Comments gladly received!
Quickly reading through it, here's a couple.
Thanks for taking a look, Ville. I'll incoorporate your suggestions in a couple of days, once other people have also commented. A couple of questions though:
- I think cases where install time dependencies on plain "emacs" or "xemacs"
are desirable are very rare. The usual problem with those is that they bind the add-on packages to the corresponding full featured variants, ie. ones built with X etc, so one can't use them with only the -nox variant installed. That's why I addded a virtual "xemacs(bin)" Provides to the xemacs and xemacs-nox packages - that'd be a better thing to have a dependency on than eg. "xemacs" unless the full featured GUI version is specifically required.
OK, I'll incoorporate that into the templates and make a note about it. Can I ask though - there's no special meaning given to parentheses in Provides: foo(bar) is there?
The emacs packages don't have that functionality (yet?), so I think the best thing for them for now would be to have a dependency on emacs-common instead of emacs or emacs-nox.
Yes; I checked and both emacs and emacs-nox Require: emacs-common so that would work.
I will open a bugzilla RFE asking for a virtual Provides: emacs(bin) though for the future, I think that's a good idea.
- At least in the XEmacs case, the dependency on xemacs(bin) should be
versioned, like "Requires: xemacs(bin) >= $evr_of_xemacs_used_to_build_the_package". The xemacs-bytecompiled *.elc files are in the vast majority of cases forwards compatible, but much less often backwards compatible. See the xemacs-packages-base and xemacs-packages-extras packages for examples. (Hm, I see those have deps on xemacs-common instead of xemacs(bin), will have a look.)
Yes, I could expliti#ly add mention of that. I had assumed that would fall within a packagers general knowledge as it's not especially significant to X#(X)Emacs. But, no harm adding it anyway, you're right.
Thanks again for the input, Jonathan.
To reply to my own post..
On 07/05/07, Jonathan Underwood jonathan.underwood@gmail.com wrote:
The emacs packages don't have that functionality (yet?), so I think the best thing for them for now would be to have a dependency on emacs-common instead of emacs or emacs-nox.
Yes; I checked and both emacs and emacs-nox Require: emacs-common so that would work.
Actually, thinking more about it, having a Requires:emacs-common is sub-optimal, as the user who oesn't have any emacs package installed could install the add-on, which would pull in emacs-commonm, but not emacs or emacs-nox.
I will open a bugzilla RFE asking for a virtual Provides: emacs(bin) though for the future, I think that's a good idea.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239374
Jonathan.
On Tuesday 08 May 2007, Jonathan Underwood wrote:
Actually, thinking more about it, having a Requires:emacs-common is sub-optimal, as the user who oesn't have any emacs package installed could install the add-on, which would pull in emacs-commonm, but not emacs or emacs-nox.
That's right, but IMHO it's the lesser evil when compared to insisting on a particular flavour of the actual emacs binary. Mileages vary and I'm not going to insist on that though ;), especially because:
I will open a bugzilla RFE asking for a virtual Provides: emacs(bin) though for the future, I think that's a good idea.
Thanks, added a comment there.
On Tuesday 08 May 2007, Jonathan Underwood wrote:
Can I ask though - there's no special meaning given to parentheses in Provides: foo(bar) is there?
No, it's just a notion commonly used in various "virtual" packages, and may help distinguishing them from real package names which are unlikely to contain parens.
Hi,
Jonathan Underwood wrote:
I have placed a draft Guidelines document on the wiki for your consideration. This document covers the packaging of Emacs and XEmacs add-on packages, and provides two template spec files with the intention of lowering the inertial barrier to developing packages for (X)Emacs. The doc can be found here: http://fedoraproject.org/wiki/PackagingDrafts/EmacsenAddOns
Thanks for doing this. I agree it would be very good to have guidelines for packaging elisp packages.
My only comment so far FWIW is that I don't like naming the source packages emacs-common-<name> so much. I think it is a bit confusing with emacs-common (an emacs subpackage) already existing and it makes the source package names rather long. (I just noticed some submitted an emacs-common-<name> package for review...)
For me at least it would make more sense just to name the main package emacs-<name> to be honest, and then sure there could still be a emacs-<name>-common package and xemacs-<name> package as appropriate. Traditionally that is what we did in the old days when we had elisp packages in RHL.
Jens
On 17/05/07, Jens Petersen petersen@redhat.com wrote:
My only comment so far FWIW is that I don't like naming the source packages emacs-common-<name> so much. I think it is a bit confusing with emacs-common (an emacs subpackage) already existing and it makes the source package names rather long. (I just noticed some submitted an emacs-common-<name> package for review...)
For me at least it would make more sense just to name the main package emacs-<name> to be honest, and then sure there could still be a emacs-<name>-common package and xemacs-<name> package as appropriate. Traditionally that is what we did in the old days when we had elisp packages in RHL.
Jens, I happen to mostly agree with you. However, the guideline I created is taking the package naming guidelines for emacs add-ons as gospel, as this was discussed a lot before being decided on, and the reasons for chosing the current scheme were a bit convoluted. See these threads for the long discussions:
https://www.redhat.com/archives/fedora-extras-list/2006-May/msg00262.html (you'll need to read through a fair few posts to see how it evolved)
https://www.redhat.com/archives/fedora-extras-list/2006-May/msg00740.html
Tom in particular was in favour of the "common" part of the naming scheme, as I recall.
Question is, do we want to revisit this?
J.
Jonathan Underwood さんは書きました:
Jens, I happen to mostly agree with you. However, the guideline I created is taking the package naming guidelines for emacs add-ons as gospel, as this was discussed a lot before being decided on, and the reasons for chosing the current scheme were a bit convoluted. See these threads for the long discussions:
https://www.redhat.com/archives/fedora-extras-list/2006-May/msg00262.html (you'll need to read through a fair few posts to see how it evolved) https://www.redhat.com/archives/fedora-extras-list/2006-May/msg00740.html
Ok thanks, that clarifies the status quo.
Tom in particular was in favour of the "common" part of the naming scheme, as I recall.
I still think the emacs-common prefix is confusing with the emacs-common package but I should have made that comment a year ago I guess. ;-) There are alternative prefix's (elisp or emacsen) that could be (have been) used but perhaps it is too late now? IMHO it would be better to avoid hyphened prefixes in package naming afap possible in the future.
Jens
On 22/05/07, Jens Petersen petersen@redhat.com wrote:
I still think the emacs-common prefix is confusing with the emacs-common package but I should have made that comment a year ago I guess. ;-) There are alternative prefix's (elisp or emacsen) that could be (have been) used but perhaps it is too late now? IMHO it would be better to avoid hyphened prefixes in package naming afap possible in the future.
Jens, you're of course right. The fact that emacs-common is a subpackage of emacs didn't come up during the discussions a year ago. I did try for "emacsen" but people didn't like that so much, am not sure why.
Anyway, I'm happy to revisit the package naming guidelines for (X)Emacs add-ons, Jens seems inclined to do so. Does anyone else have strong feelings either way?
Jonathan
On Tue, 2007-05-22 at 10:29 +0100, Jonathan Underwood wrote:
On 22/05/07, Jens Petersen petersen@redhat.com wrote:
I still think the emacs-common prefix is confusing with the emacs-common package but I should have made that comment a year ago I guess. ;-) There are alternative prefix's (elisp or emacsen) that could be (have been) used but perhaps it is too late now? IMHO it would be better to avoid hyphened prefixes in package naming afap possible in the future.
Jens, you're of course right. The fact that emacs-common is a subpackage of emacs didn't come up during the discussions a year ago. I did try for "emacsen" but people didn't like that so much, am not sure why.
Anyway, I'm happy to revisit the package naming guidelines for (X)Emacs add-ons, Jens seems inclined to do so. Does anyone else have strong feelings either way?
I'm not convinced that emacs-common-foo is broken as a naming scheme. It seems more intuitive than emacsen to me.
Then again, I'm not an emacs user.
~spot
Sorry I failed to follow to this thread earlier, rolled off my radar. :/ (I need to find a better way of tracking followups to my posts...)
Tom "spot" Callaway さんは書きました:
On Tue, 2007-05-22 at 10:29 +0100, Jonathan Underwood wrote:
On 22/05/07, Jens Petersen petersen@redhat.com wrote:
I still think the emacs-common prefix is confusing with the emacs-common package [...]
Jens, you're of course right. The fact that emacs-common is a subpackage of emacs didn't come up during the discussions a year ago. I did try for "emacsen" but people didn't like that so much, am not sure why.
Well I don't like "emacsen" either...
Anyway, I'm happy to revisit the package naming guidelines for (X)Emacs add-ons, Jens seems inclined to do so. Does anyone else have strong feelings either way?
My suggestion is just to go with emacs-* rather than emacs-common-*. It is a pretty small change and already quite a number of older elisp packages follow it.
I'm not convinced that emacs-common-foo is broken as a naming scheme.
IMHO it is too verbose and it makes it hard to read and find emacs packages.
Then again, I'm not an emacs user.
I think it would be better if emacs/xemacs users had more say in setting the naming convention.
Jens
On 18/07/07, Jens Petersen petersen@redhat.com wrote:
Well I don't like "emacsen" either...
Anyway, I'm happy to revisit the package naming guidelines for (X)Emacs add-ons, Jens seems inclined to do so. Does anyone else have strong feelings either way?
My suggestion is just to go with emacs-* rather than emacs-common-*. It is a pretty small change and already quite a number of older elisp packages follow it.
Jens, please review the previous discussions on this so we don't have to rehash exactly the same old arguments - in this thread I have earlier pointed to the past discussions.
The problem arises when a package is an add-on for both GNU Emacs and XEmacs. In that case there ARE subpackages called emacs-foo and xemacs-foo for each flavour. But that means the main package name can't also be emacs-foo.
I'm not convinced that emacs-common-foo is broken as a naming scheme.
IMHO it is too verbose and it makes it hard to read and find emacs packages.
Why? I want to install the muse package for Emacs. So I type yum install emacs-muse. That of course also pulls in emacs-common-muse. What is so hard about this for a user?
Then again, I'm not an emacs user.
I think it would be better if emacs/xemacs users had more say in setting the naming convention.
Well, I agree, but this mailing list is the forum for that to happen. Emacs/XEmacs users are having the same opportunities to comment on package naming guidelines here that users generally have to comment on package naming (i.e. not a lot).
On 18/07/07, Jens Petersen petersen@redhat.com wrote:
My suggestion is just to go with emacs-* rather than emacs-common-*. It is a pretty small change and already quite a number of older elisp packages follow it.
If I understand correctly, this would translate to:
main package: emacs-foo, containing files specific to GNU Emacs sub package: emacs-foo-common, containing files not specific to any Emacs flavour sub-package: xemacs-foo, containing files specific to XEmacs sub-packages: xemacs-foo-el and emacs-foo-el containing the lisp source for each flavour.
This is essentially was my very first original proposal, but people weren't keen on it as it uses the term emacs as a generalization for emacs flavours, and as a specific for GNU Emacs.
I do happen to prefer this though, and tend to agree with Jens. If I recall, at least Tom didn't like it.
J.
On 20/07/07, Jonathan Underwood jonathan.underwood@gmail.com wrote:
If I understand correctly, this would translate to:
main package: emacs-foo, containing files specific to GNU Emacs sub package: emacs-foo-common, containing files not specific to any Emacs flavour sub-package: xemacs-foo, containing files specific to XEmacs sub-packages: xemacs-foo-el and emacs-foo-el containing the lisp source for each flavour.
This is essentially was my very first original proposal, but people weren't keen on it as it uses the term emacs as a generalization for emacs flavours, and as a specific for GNU Emacs.
I should also point out that the above proposal doesn't treat GNU Emacs and XEmacs on an equal footing - the XEmacs package being a sub package and the GNU Emacs package being the main package. The current emacs-common-foo scheme does not have that bias.
On Fri, 2007-07-20 at 11:20 +0100, Jonathan Underwood wrote:
On 20/07/07, Jonathan Underwood jonathan.underwood@gmail.com wrote:
If I understand correctly, this would translate to:
main package: emacs-foo, containing files specific to GNU Emacs sub package: emacs-foo-common, containing files not specific to any Emacs flavour sub-package: xemacs-foo, containing files specific to XEmacs sub-packages: xemacs-foo-el and emacs-foo-el containing the lisp source for each flavour.
This is essentially was my very first original proposal, but people weren't keen on it as it uses the term emacs as a generalization for emacs flavours, and as a specific for GNU Emacs.
I should also point out that the above proposal doesn't treat GNU Emacs and XEmacs on an equal footing - the XEmacs package being a sub package and the GNU Emacs package being the main package. The current emacs-common-foo scheme does not have that bias.
This is one of the main reasons why I prefer the current scheme, because I don't have to pull people apart while fighting "my editor is better" wars. :)
~spot
Hi,
Chip has now fixed the Emacs packages in a way that is consistent with Xemacs packaging (thanks chip!) and so I have finished the draft (X)Emacs add-on packging guideline draft here:
http://fedoraproject.org/wiki/PackagingDrafts/EmacsenAddOns
Comment/edits very welcome. Hopefully this can go to the committee before too long.
Jonathan.
On 15/08/07, Jonathan Underwood jonathan.underwood@gmail.com wrote:
Hi,
Chip has now fixed the Emacs packages in a way that is consistent with Xemacs packaging (thanks chip!) and so I have finished the draft (X)Emacs add-on packging guideline draft here:
http://fedoraproject.org/wiki/PackagingDrafts/EmacsenAddOns
Comment/edits very welcome. Hopefully this can go to the committee before too long.
I just went to update this page accordingly:
http://fedoraproject.org/wiki/Packaging/GuidelinesTodo
but find that it is immutable. Perhaps someone could update it for me - the status column reading "Waiting on Bugzillas" for the EmacsAddOns page should now read "ASAP" or similar.
J.
Jonathan Underwood wrote:
I just went to update this page accordingly:
http://fedoraproject.org/wiki/Packaging/GuidelinesTodo
but find that it is immutable. Perhaps someone could update it for me
- the status column reading "Waiting on Bugzillas" for the EmacsAddOns
page should now read "ASAP" or similar.
ASAP it is, fixed.
-- Rex
On 15/08/07, Rex Dieter rdieter@math.unl.edu wrote:
Jonathan Underwood wrote:
I just went to update this page accordingly:
http://fedoraproject.org/wiki/Packaging/GuidelinesTodo
but find that it is immutable. Perhaps someone could update it for me
- the status column reading "Waiting on Bugzillas" for the EmacsAddOns
page should now read "ASAP" or similar.
ASAP it is, fixed.
Thanks.
On Wed, 2007-08-15 at 17:02 +0100, Jonathan Underwood wrote:
On 15/08/07, Jonathan Underwood jonathan.underwood@gmail.com wrote:
Hi,
Chip has now fixed the Emacs packages in a way that is consistent with Xemacs packaging (thanks chip!) and so I have finished the draft (X)Emacs add-on packging guideline draft here:
http://fedoraproject.org/wiki/PackagingDrafts/EmacsenAddOns
Comment/edits very welcome. Hopefully this can go to the committee before too long.
I just went to update this page accordingly:
http://fedoraproject.org/wiki/Packaging/GuidelinesTodo
but find that it is immutable. Perhaps someone could update it for me
- the status column reading "Waiting on Bugzillas" for the EmacsAddOns
page should now read "ASAP" or similar.
FYI: That table gets sucked in from: PackagingDrafts/DraftsTodo, which anyone can edit.
~spot
On 15/08/07, Tom spot Callaway tcallawa@redhat.com wrote:
FYI: That table gets sucked in from: PackagingDrafts/DraftsTodo, which anyone can edit.
Aha, thanks.
Regarding the current Emacsen add-on draft,
* Added some more info about requiring a version of (X)Emacs newer than or equal to the one used to compile the *.elcs, and how to find that version out dynamically during package build.
* I'd like to see something mentioned about packaging *.el snippets that aren't full blown packages of their own, see for example rpmdevtools.
On 27/05/07, Ville Skyttä ville.skytta@iki.fi wrote:
Regarding the current Emacsen add-on draft,
- Added some more info about requiring a version of (X)Emacs newer than or
equal to the one used to compile the *.elcs, and how to find that version out dynamically during package build.
Thanks very much, Ville.
- I'd like to see something mentioned about packaging *.el snippets that
aren't full blown packages of their own, see for example rpmdevtools.
Yes, actually Tom Tromey had also mentioned this to me privately, and you're both right - we do need to mention this. There are actually a lot of cases where a piece of software has a mode for eg. editing input files for that software.
Another example that springs to mind is gnuplot, which has a subpackage called gnuplot-emacs which installs
gnuplot.el gnuplot.elc gnuplot-gui.el gnuplot-gui.elc info-look.20.2.el info-look.20.3.el
for GNU Emacs in /usr/share/emacs/site-lisp.
There are a couple of things with this which I suppose are inconsistent with the guidelines for full blown emacs add-on packages:
1) The source .el files aren't in a separate sub-package called gnuplot-emacs-el 2) The files aren't installed in their own sub-directory /usr/share/emacs/site-lisp/gnuplot 3) The info-look.20.[2,3].el files aren't byte compiled (there may be good reasons for this.
Similarly on my system currently I see the same issues for:
1) rpmdevtools (rpm-spec-mode.el[c], 2) desktop-file-utils (desktop-entry-mode.el[c]) 3) libidn (idna.el and no idna.elc) 4) emacs-common (has extra files like php-mode.el, po-mode.el, python-mode.el, ssl.el not in emacs-common-el and also not in their own directories)
I would propose guidelines such as these: 1) Packages which include add on modes for (X)Emacs should package the byte compiled lisp files for these modes in a sub-package named foo-emacs and/or foo-xemacs.
2) Packages which include add on modes for (X)Emacs should package the source elisp files in separate subpackges called foo-emacs-el and foo-xemacs-el.
3) Elisp add on subpackages should install their files in an appropriately named subdirectory of /usr/share/emacs/site-lisp and /usr/share/xemacs/site-packages/lisp. These directories should be owned by the foo-emacs and foo-xemacs packages respectively.
4) foo-emacs-el should have Requires: foo-emacs and foo-xemacs-el should have Requires: foo-xemacs.
These seem logically consistent with the guidelines formain (X)Emacs add-on packages, but don't fit with current packaging of some packages. The current situation is rather inconsistent.
I agree with Ville, I think it's important that the draft include something on this matter.
Best wishes, Jonathan.
On Sunday 27 May 2007, Jonathan Underwood wrote:
I would propose guidelines such as these:
- Packages which include add on modes for (X)Emacs should package the
byte compiled lisp files for these modes in a sub-package named foo-emacs and/or foo-xemacs.
I don't agree with that naming - it doesn't follow the "if it's bar for foo, call it foo-bar" naming strategy applied to just about everything else. emacs-foo and xemacs-foo would be better. Ditto emacs-foo-el, xemacs-foo-el.
Otherwise, looks good to me.
On 27/05/07, Ville Skyttä ville.skytta@iki.fi wrote:
On Sunday 27 May 2007, Jonathan Underwood wrote:
I would propose guidelines such as these:
- Packages which include add on modes for (X)Emacs should package the
byte compiled lisp files for these modes in a sub-package named foo-emacs and/or foo-xemacs.
I don't agree with that naming - it doesn't follow the "if it's bar for foo, call it foo-bar" naming strategy applied to just about everything else. emacs-foo and xemacs-foo would be better. Ditto emacs-foo-el, xemacs-foo-el.
Otherwise, looks good to me.
Yes - I had that thought initially too. But it becomes a question of is the mode an add on for Emacs or an add-on for gnuplot (in the example given). In the end, I couldn't decide either way. Thing is, current precedent is foo-emacs, so if we're more infavour of emacs-foo, which is much more consistent, I agree, then a fair few packages will need to be renamed.
OTOH, whatever guideline we introduce here will mean some packaging work will need to be done on existing packages. So perhaps we should just get it right once and for all.
I'll wait a while, and if there are no more comments I'll add these guidelines along with your namingporeference to the wiki page.
J.
On 27/05/07, Jonathan Underwood jonathan.underwood@gmail.com wrote:
On 27/05/07, Ville Skyttä ville.skytta@iki.fi wrote:
On Sunday 27 May 2007, Jonathan Underwood wrote:
I would propose guidelines such as these:
- Packages which include add on modes for (X)Emacs should package the
byte compiled lisp files for these modes in a sub-package named foo-emacs and/or foo-xemacs.
I don't agree with that naming - it doesn't follow the "if it's bar for foo, call it foo-bar" naming strategy applied to just about everything else. emacs-foo and xemacs-foo would be better. Ditto emacs-foo-el, xemacs-foo-el.
Otherwise, looks good to me.
Yes - I had that thought initially too. But it becomes a question of is the mode an add on for Emacs or an add-on for gnuplot (in the example given). In the end, I couldn't decide either way. Thing is, current precedent is foo-emacs, so if we're more infavour of emacs-foo, which is much more consistent, I agree, then a fair few packages will need to be renamed.
OTOH, whatever guideline we introduce here will mean some packaging work will need to be done on existing packages. So perhaps we should just get it right once and for all.
I'll wait a while, and if there are no more comments I'll add these guidelines along with your namingporeference to the wiki page.
I have now updated the Guidelines to reflect this issue. Actually, the approach I have taken is to add an executive summary at the top of the page which encompasses this. See what you think.
J.
On 27/05/07, Ville Skyttä ville.skytta@iki.fi wrote:
Regarding the current Emacsen add-on draft,
- Added some more info about requiring a version of (X)Emacs newer than or
equal to the one used to compile the *.elcs, and how to find that version out dynamically during package build.
Actually, I was just testing this, and it doesn't work.
You added these macros: %define emacsversion v=$(rpm -q --qf=%%{VERSION} emacs) ; case $v in 2*) echo $v ;; *) echo 0 ;; esac
%define xemacsversion v=$(rpm -q --qf=%%{VERSION} xemacs) ; case $v in 2*) echo $v ;; *) echo 0 ;; esac
And so whenthere is a Requires: emacs-common >= %{emacsversion} you get an error like this:
error: line 21: Dependency tokens must begin with alpha-numeric, '_' or '/': Requires: emacs-common >= v=$(rpm -q --qf=%{VERSION} emacs) ; case $v in 2*) echo $v ;; *) echo 0 ;; esac
J.
On 30/05/07, Jonathan Underwood jonathan.underwood@gmail.com wrote:
On 27/05/07, Ville Skyttä ville.skytta@iki.fi wrote:
Regarding the current Emacsen add-on draft,
- Added some more info about requiring a version of (X)Emacs newer than or
equal to the one used to compile the *.elcs, and how to find that version out dynamically during package build.
Actually, I was just testing this, and it doesn't work.
You added these macros: %define emacsversion v=$(rpm -q --qf=%%{VERSION} emacs) ; case $v in 2*) echo $v ;; *) echo 0 ;; esac
%define xemacsversion v=$(rpm -q --qf=%%{VERSION} xemacs) ; case $v in 2*) echo $v ;; *) echo 0 ;; esac
And so whenthere is a Requires: emacs-common >= %{emacsversion} you get an error like this:
error: line 21: Dependency tokens must begin with alpha-numeric, '_' or '/': Requires: emacs-common >= v=$(rpm -q --qf=%{VERSION} emacs) ; case $v in 2*) echo $v ;; *) echo 0 ;; esac
Also, this wouldn't work as intended on a system where more than one arch of the emacs package is installed - eg. on my system i seem to have emacs.x86_64 and emacs.i386 installed, and so
rpm -q --qf=%{VERSION} emacs
gives 22.0.9922.0.99.
Granted, that wouldn't happen in a mock chroot buildroot, but still, I think we should do a bit better than that :) Can't see how though :(
J.
J.
On Wednesday 30 May 2007, Jonathan Underwood wrote:
On 30/05/07, Jonathan Underwood jonathan.underwood@gmail.com wrote:
Also, this wouldn't work as intended on a system where more than one arch of the emacs package is installed - eg. on my system i seem to have emacs.x86_64 and emacs.i386 installed, and so
rpm -q --qf=%{VERSION} emacs
gives 22.0.9922.0.99.
Granted, that wouldn't happen in a mock chroot buildroot, but still, I think we should do a bit better than that :) Can't see how though :(
Perhaps something like this (untested):
rpm -qf --qf="%{VERSION}\n" /usr/bin/emacs | head -n 1
I'm sure there's a limit somewhere how far we're willing to take these tweaks though.
On Wed, 2007-05-30 at 00:26 +0100, Jonathan Underwood wrote:
On 27/05/07, Ville Skyttä ville.skytta@iki.fi wrote:
Regarding the current Emacsen add-on draft,
- Added some more info about requiring a version of (X)Emacs newer than or
equal to the one used to compile the *.elcs, and how to find that version out dynamically during package build.
Actually, I was just testing this, and it doesn't work.
You added these macros: %define emacsversion v=$(rpm -q --qf=%%{VERSION} emacs) ; case $v in 2*) echo $v ;; *) echo 0 ;; esac
%define xemacsversion v=$(rpm -q --qf=%%{VERSION} xemacs) ; case $v in 2*) echo $v ;; *) echo 0 ;; esac
Good lord. No. Thou shalt not query rpm inside rpm.
Ask emacs/xemacs what version it is.
~spot
On Wednesday 30 May 2007, Tom "spot" Callaway wrote:
On Wed, 2007-05-30 at 00:26 +0100, Jonathan Underwood wrote:
On 27/05/07, Ville Skyttä ville.skytta@iki.fi wrote:
Regarding the current Emacsen add-on draft,
- Added some more info about requiring a version of (X)Emacs newer than
or equal to the one used to compile the *.elcs, and how to find that version out dynamically during package build.
Actually, I was just testing this, and it doesn't work.
You added these macros: %define emacsversion v=$(rpm -q --qf=%%{VERSION} emacs) ; case $v in 2*) echo $v ;; *) echo 0 ;; esac
%define xemacsversion v=$(rpm -q --qf=%%{VERSION} xemacs) ; case $v in 2*) echo $v ;; *) echo 0 ;; esac
Good lord. No. Thou shalt not query rpm inside rpm.
Disagreed, when done carefully.
Ask emacs/xemacs what version it is.
$ emacs --version GNU Emacs 22.0.95.1 Copyright (C) 2007 Free Software Foundation, Inc. GNU Emacs comes with ABSOLUTELY NO WARRANTY. You may redistribute copies of Emacs under the terms of the GNU General Public License. For more information about these matters, see the file named COPYING.
$ xemacs --version XEmacs 21.5 (beta28) "fuki" [Lucid] (x86_64-redhat-linux, Mule) of Sat May 26 2007 on viper.bobcat.mine.nu
Very much fun parsing those and creating a string that matches what the corresponding emacs/xemacs package's version is, when we can just simply ask rpm.
On Wed, 2007-05-30 at 09:47 +0300, Ville Skyttä wrote:
On Wednesday 30 May 2007, Tom "spot" Callaway wrote:
On Wed, 2007-05-30 at 00:26 +0100, Jonathan Underwood wrote:
On 27/05/07, Ville Skyttä ville.skytta@iki.fi wrote:
Regarding the current Emacsen add-on draft,
- Added some more info about requiring a version of (X)Emacs newer than
or equal to the one used to compile the *.elcs, and how to find that version out dynamically during package build.
Actually, I was just testing this, and it doesn't work.
You added these macros: %define emacsversion v=$(rpm -q --qf=%%{VERSION} emacs) ; case $v in 2*) echo $v ;; *) echo 0 ;; esac
%define xemacsversion v=$(rpm -q --qf=%%{VERSION} xemacs) ; case $v in 2*) echo $v ;; *) echo 0 ;; esac
Good lord. No. Thou shalt not query rpm inside rpm.
Disagreed, when done carefully.
There is no careful way to do it. It is not safe, it is not predictable, it is not reproducable.
emacs --version | head -n1 | sed -e 's/[^0-9.]//g' xemacs -V -no-site-file | cut -d " " -f 2
Not that hard.
~spot
On Wednesday 30 May 2007, Tom "spot" Callaway wrote:
On Wed, 2007-05-30 at 09:47 +0300, Ville Skyttä wrote:
On Wednesday 30 May 2007, Tom "spot" Callaway wrote:
Good lord. No. Thou shalt not query rpm inside rpm.
Disagreed, when done carefully.
There is no careful way to do it. It is not safe, it is not predictable, it is not reproducable.
My experience says otherwise, so would you care to elaborate and back each of those claims up with some concrete examples, in particular explaining in which way querying rpm is less $something than querying emacs or xemacs in that case?
emacs --version | head -n1 | sed -e 's/[^0-9.]//g' xemacs -V -no-site-file | cut -d " " -f 2
Not that hard.
And both of those have a fundamental issue that they're disconnect with what we need - the rpm *package* version; unless of course emacs/xemacs add a versioned Provides or something like the httpd-mmn mechanism in the httpd package that aligns better with what can be retrieved from querying them or something non-rpm.
They also lack the possibility of querying Epochs (not needed currently in the *emacs case, just mentioning because you generalized all rpm querying as bad), and the output of those commands need to be watched and verified between upstream revisions (which sooner or later results in a mess of tweaks or inability to support all versions which would be useful), and user init files possibly suppressed more than in the above, etc. BTW, the xemacs version above produces wrong results; we want eg. 21.5.27, not 21.5.
Ville Skyttä wrote:
On Wednesday 30 May 2007, Tom "spot" Callaway wrote:
On Wed, 2007-05-30 at 09:47 +0300, Ville Skyttä wrote:
On Wednesday 30 May 2007, Tom "spot" Callaway wrote:
Good lord. No. Thou shalt not query rpm inside rpm.
Disagreed, when done carefully.
There is no careful way to do it. It is not safe, it is not predictable, it is not reproducable.
My experience says otherwise, so would you care to elaborate and back each of those claims up with some concrete examples
Been there, done that. Echo'ing what spot said, don't.
One concrete example: chroot'd buildroots (like mock). The rpm version used to create the buildroot (oftentimes) != rpm version used inside the root for the query, leads to wierd behavior, failures.
-- Rex
On Wednesday 30 May 2007, Rex Dieter wrote:
One concrete example: chroot'd buildroots (like mock). The rpm version used to create the buildroot (oftentimes) != rpm version used inside the root for the query, leads to wierd behavior, failures.
If I understand correctly, this is an orthogonal issue which isn't limited to querying rpm. For example, different *emacs versions inside and outside the buildroot is just as likely as different rpm versions. What makes querying them for versions instead of rpm safer, more predictable, and more reproducible?
On Wednesday 30 May 2007 15:47:21 Ville Skyttä wrote:
If I understand correctly, this is an orthogonal issue which isn't limited to querying rpm. For example, different *emacs versions inside and outside the buildroot is just as likely as different rpm versions. What makes querying them for versions instead of rpm safer, more predictable, and more reproducible?
Because you're querying the emacs in the chroot not outside the chroot. In the case of rpm, the rpm _outside_ the chroot was used to populate the chroot, and the rpm database version that winds up in said chroot does not match the version of rpm that gets installed inside the chroot. emacs won't have this problem.
On Wednesday 30 May 2007, Jesse Keating wrote:
On Wednesday 30 May 2007 15:47:21 Ville Skyttä wrote:
If I understand correctly, this is an orthogonal issue which isn't limited to querying rpm. For example, different *emacs versions inside and outside the buildroot is just as likely as different rpm versions. What makes querying them for versions instead of rpm safer, more predictable, and more reproducible?
Because you're querying the emacs in the chroot not outside the chroot. In the case of rpm, the rpm _outside_ the chroot was used to populate the chroot, and the rpm database version that winds up in said chroot does not match the version of rpm that gets installed inside the chroot.
mock runs rpmbuild inside the chroot. Why doesn't it break? --nodeps?
On Wednesday 30 May 2007 16:27:40 Ville Skyttä wrote:
mock runs rpmbuild inside the chroot. Why doesn't it break? --nodeps?
Probably. All the deps are resolved before the build begins.
On Wed, 2007-05-30 at 23:27 +0300, Ville Skyttä wrote:
On Wednesday 30 May 2007, Jesse Keating wrote:
On Wednesday 30 May 2007 15:47:21 Ville Skyttä wrote:
If I understand correctly, this is an orthogonal issue which isn't limited to querying rpm. For example, different *emacs versions inside and outside the buildroot is just as likely as different rpm versions. What makes querying them for versions instead of rpm safer, more predictable, and more reproducible?
Because you're querying the emacs in the chroot not outside the chroot. In the case of rpm, the rpm _outside_ the chroot was used to populate the chroot, and the rpm database version that winds up in said chroot does not match the version of rpm that gets installed inside the chroot.
mock runs rpmbuild inside the chroot. Why doesn't it break? --nodeps?
all the operations performed on the rpmdb in the chroot are done from outside the chroot, not inside.
-sv
OK, interesting as all that was, I don't think we reached a conclusion:
a) can we query rpm inside a spec or not?
b) If no to (a) can we go about ascertaining the build time emacs version reliably some other way.
c) If no to (b), is it acceptable to have packagers putting the Requires: emacs >= N.n.nn in themselves?
[In the past, I've always done c].
J.
On 31/05/07, Tom spot Callaway tcallawa@redhat.com wrote:
On Thu, 2007-05-31 at 11:56 +0100, Jonathan Underwood wrote:
OK, interesting as all that was, I don't think we reached a conclusion:
a) can we query rpm inside a spec or not?
I'm standing on a firm NO here.
OK.
So how do we feel about
emacs --no-site-file --version | head -n1 | awk '{print $3}'
and
xemacs --no-site-file --version | head -n1 | awk '{print $2}'
(not guaranteed that it will work in future emacs versions which may change their formatting of --version info.)
~spot
-- Fedora-packaging mailing list Fedora-packaging@redhat.com https://www.redhat.com/mailman/listinfo/fedora-packaging
On Thursday 31 May 2007, Jonathan Underwood wrote:
So how do we feel about
emacs --no-site-file --version | head -n1 | awk '{print $3}'
and
xemacs --no-site-file --version | head -n1 | awk '{print $2}'
(not guaranteed that it will work in future emacs versions which may change their formatting of --version info.)
Bad, as explained before. Instead, how about adding some pkgconfig files which are generated during build and thus we have complete control over their contents? Eg. the attached one to xemacs-devel:
$ pkg-config xemacs --modversion 21.5.28 $ pkg-config xemacs --variable=sitestartdir /usr/share/xemacs/site-packages/lisp/site-start.d $ pkg-config xemacs --variable=sitepkglispdir /usr/share/xemacs/site-packages/lisp $ pkg-config xemacs --variable=sitemoduledir /usr/lib64/xemacs/site-modules $ pkg-config xemacs --cflags -I/usr/lib64/xemacs-21.5-b28/x86_64-redhat-linux/include
On 31/05/07, Ville Skyttä ville.skytta@iki.fi wrote:
Bad, as explained before. Instead, how about adding some pkgconfig files which are generated during build and thus we have complete control over their contents? Eg. the attached one to xemacs-devel:
$ pkg-config xemacs --modversion 21.5.28 $ pkg-config xemacs --variable=sitestartdir /usr/share/xemacs/site-packages/lisp/site-start.d $ pkg-config xemacs --variable=sitepkglispdir /usr/share/xemacs/site-packages/lisp $ pkg-config xemacs --variable=sitemoduledir /usr/lib64/xemacs/site-modules $ pkg-config xemacs --cflags -I/usr/lib64/xemacs-21.5-b28/x86_64-redhat-linux/include
Perfect! That also allows package build time discovery of the site-lisp directories etc.
I wonder if Chip would be willing to add such a thing to GNU Emacs package.
J.
Ville Skyttä wrote:
Instead, how about adding some pkgconfig files which are generated during build and thus we have complete control over their contents?
Much better (or some other equivalent mechanism not involving rpm queries).
-- Rex
On 31/05/07, Rex Dieter rdieter@math.unl.edu wrote:
Ville Skyttä wrote:
Instead, how about adding some pkgconfig files which are generated during build and thus we have complete control over their contents?
Much better (or some other equivalent mechanism not involving rpm queries).
OK, have filed a BZ requesting that this approach be adopted in Emacs. Once that is done we will be able to move forward.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=242176
Until that bug, and this one:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239374
progress further, I don't think I can finish the draft, so there's no point bringing this before the packaging committee just yet.
J.
I don
-- Rex
-- Fedora-packaging mailing list Fedora-packaging@redhat.com https://www.redhat.com/mailman/listinfo/fedora-packaging
On Wed, 2007-05-30 at 20:20 +0300, Ville Skyttä wrote:
And both of those have a fundamental issue that they're disconnect with what we need - the rpm *package* version; unless of course emacs/xemacs add a versioned Provides or something like the httpd-mmn mechanism in the httpd package that aligns better with what can be retrieved from querying them or something non-rpm.
Do you really need that fine grained of a version? Is emacs/xemacs that picky, that the API/ABI breaks on releases? That you have to match to the exact package?
~spot
On Wednesday 30 May 2007, Tom "spot" Callaway wrote:
On Wed, 2007-05-30 at 20:20 +0300, Ville Skyttä wrote:
And both of those have a fundamental issue that they're disconnect with what we need - the rpm *package* version; unless of course emacs/xemacs add a versioned Provides or something like the httpd-mmn mechanism in the httpd package that aligns better with what can be retrieved from querying them or something non-rpm.
Do you really need that fine grained of a version? Is emacs/xemacs that picky, that the API/ABI breaks on releases? That you have to match to the exact package?
I can't speak for GNU Emacs, however I have some years of past experience as the upstream XEmacs packages release manager, and I guess things aren't that different with GNU Emacs. (Note: in this context, "package" has nothing to do with rpm - think more like a CPAN module distribution tarball.)
The issue is not API/ABI breakage within XEmacs per se, but that a lot of elisp packages (especially ones that aren't part of upstream XEmacs packages collection and are thus likely candidates for being rpm-packaged separately) aim for backwards source level compatibility by checking whether some features exist in the XEmacs in use when the package is being run or byte-compiled. If yes, they use what's available. If no, they provide their own versions of missing functions, macros etc. This propagates into *.elc, and quite a few functions do get added between upstream releases, especially in the current beta branch of XEmacs that is being shipped in Fedora.
So let's say I byte-compile a package into *.elc with XEmacs 21.5.28. Elisp package quux checks if the foo-bar function is available in the XEmacs being used to byte-compile it. Yes, it is, so the internal backwards compat version of foo-bar included in quux does not end up in the *.elc. Now, let's assume foo-bar was added in XEmacs 21.5.28 and didn't exist in 21.5.27 and we're trying to run the *.elc with 21.5.27 -> boom, foo-bar is not available. Note: this wouldn't happen if only *.el were shipped - *.elc are the potential and likely problem. Requiring >= version of the XEmacs used to byte-compile the *.elc is not the only solution (nor enough for all corner cases), but I can't think of a better generic way out that would be appropriate for the vast majority of cases.
On Wednesday 30 May 2007, Jonathan Underwood wrote:
Actually, I was just testing this, and it doesn't work.
You added these macros: %define emacsversion v=$(rpm -q --qf=%%{VERSION} emacs) ; case $v in 2*) echo $v ;; *) echo 0 ;; esac
%define xemacsversion v=$(rpm -q --qf=%%{VERSION} xemacs) ; case $v in 2*) echo $v ;; *) echo 0 ;; esac
And so whenthere is a Requires: emacs-common >= %{emacsversion} you get an error like this:
error: line 21: Dependency tokens must begin with alpha-numeric, '_' or '/': Requires: emacs-common >= v=$(rpm -q --qf=%{VERSION} emacs) ; case $v in 2*) echo $v ;; *) echo 0 ;; esac
Oops, that's right. Forgot that those macros need to be referred to like %(%{emacsversion}), not plain %{emacsversion}. Fixed.
packaging@lists.fedoraproject.org
-
Jens-Ulrik Petersen -
Jesse Keating -
Jonathan Underwood -
Rex Dieter -
seth vidal -
Tom Callaway -
Ville Skyttä