Bug 181404
Summary: | Review Request: emacs-common-muse | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Jonathan Underwood <jonathan.underwood> |
Component: | Package Review | Assignee: | Kevin Fenzi <kevin> |
Status: | CLOSED NEXTRELEASE | QA Contact: | Fedora Package Reviews List <fedora-package-review> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | rawhide | CC: | coldwell, petersen, tagoh, wtogami |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2006-04-26 16:50:36 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 163779 |
Description
Jonathan Underwood
2006-02-13 20:44:33 UTC
Should have mentioned: This is my first package for FE, and I require a sponsor. How about xemacs? Fedora Core does not contain xemacs, though it is available from extras. Other packages, eg. auctex, do not support xemacs. I don't have any interest in supporting it really Once this package is in FE, I will create a sister xemacs-muse package if it is felt necessary. Not a full review yet, but a few comments: - Should name the package 'muse' as thats the name of the upstream source file. - Using %package -n emacs-muse and %package xemacs-muse should allow you to do XEmacs and Emacs packages from this same spec file. You should be able to use a sed command in there to set the EMACS= variable to the right thing. - Don't include the .jgu in Release. :) Will try and look at doing a full review soon. Thanks for taking a look at the package, Kevin. Regarding the package name issue: fedora-extras package naming guidelines state that "If a new package is considered an "addon" package that enhances or adds a new functionality to an existing Fedora Core or Fedora Extras package without being useful on its own, its name should reflect this fact. The new package ("child") should prepend the "parent" package in its name, in the format: %{parent}-%{child}." muse is an add-on package for emacs (it doesn't function without emacs), and I think I have have followed the convention accordingly. This is the same as for other emacs add-on packages, for example emacs-auctex. It's not the same though as packages that used to be in core, eg. mew, which IMHO the fact that they don't follow fedora-extras guidelines is a bug. Regarding Xemacs: I could produce xemacs-muse and emacs-muse from the same spec file, however this brings complexity and makes it a bigger job to maintain. Complexity comes because I would have to do two makes and make installs, with both makes in the %install section of the spec (see eg. muse) - this is messy, I think Also, I would end up with emacs-muse, xemacs-muse, emacs-muse-el, xemacs-muse-el packages, from a emacs-muse src rpm - I'm not sure this is desireable, a SRPM producing packages with different names. I don't wish to be disagreeable, but I think I'm doing the right thing with regard to naming, or the guidelines should be re-written. Since eg. emacs-auctex doesn't support xemacs, I don't think a lack of an xemacs package should be a blocker - I am prepared to add in the xemacs stuff though, once we've resolved the package naming issue. auctex is not a good example; it is shipped for XEmacs in the xemacs-sumo package. Updated spec file and src rpm which builds Muse for both emacs and Xemacs can be found at: http://physics.open.ac.uk/~ju83/muse.spec http://physics.open.ac.uk/~ju83/muse-3.02.6a-2.src.rpm This source file generates several packages: The common rpm that is generated is called muse, which contains documentation files. emacs-muse and xemacs-muse contain the lisp files for emacs and xemacs, and emacs-muse-el and xemacs-muse-el install the source lisp files. Building for both emacs and xemacs AND complying with the naming guidelines for fedora extras is really proving difficult, but I think this is the best compromise. I would really appreciate a review and a sponsor, as I have other packages to contribute, but this is my first package. Thanks for looking :) Greetings, here is a review: MUST items: OK - Package name good. OK - Spec file name matches OK - Package guidelines OK - Licsense. OK - License field matches in spec. OK - Spec in american english OK - Spec legible OK - Md5sum of source from upstream 96a074a0e7d5cc7b7f54012df574d6cf muse-3.02.6a.tar.gz 96a074a0e7d5cc7b7f54012df574d6cf muse-3.02.6a.tar.gz.1 OK - Compiles and builds on one arch at least. OK - no Forbidden buildrequires included. OK - Owns all directories it creates. OK - No duplicate files in %files listing. OK - Permissions on files correct. OK - Clean section correct. OK - Macros consistant. OK - Code not content. OK - Docs must not affect runtime. OK - Doesn't own any files/dirs that are already owned by others. blockers: 1. missing BuildRequires: texinfo 2. rpmlint issues: E: muse info-dir-file /usr/share/info/dir W: muse incoherent-version-in-changelog 3.02.6a 3.02.6a-2 W: muse doc-file-dependency /usr/share/doc/muse-3.02.6a/examples/johnw/publish-johnw /bin/bash W: muse doc-file-dependency /usr/share/doc/muse-3.02.6a/examples/publish-project /bin/bash W: emacs-muse no-documentation W: emacs-muse-el no-documentation W: xemacs-muse-el no-documentation W: xemacs-muse no-documentation all can be ignored, except for the Error with info-dir-file. That file is created when you build as root, suggest: rm -f $RPM_BUILD_ROOT/usr/share/info/dir in install. nits: 3. Might ask upstream to start including the GPL COPYING file with the release. Thank you for your review Kevin - I appreciate the time spent. I hope I have addressed all the blockers in this update: Spec Name or Url: http://physics.open.ac.uk/~ju83/emacs-muse.spec SRPM Name or Url: http://physics.open.ac.uk/~ju83/emacs-muse-3.02.6a- 3.jgu.src.rpm Also, I have reported the missing COPYING file upstream. Humm...should those links point to 'muse' or 'emacs-muse'? Is this based off the old emacs only version? Can you check links and let me know which one is the most up to date? Apologies, I did a poor job of copying and pasting. The correct links are: http://physics.open.ac.uk/~ju83/muse.spec http://physics.open.ac.uk/~ju83/muse-3.02.6a-3.src.rpm This version is the emacs+xemacs version, adjusted only to reflect your (Kevin's) review. Excellent. That looks much better. The blockers are all fixed, so this package is APPROVED. I will be happy to sponsor you. Continute the process from the "Get a Fedora Account" section at: http://fedoraproject.org/wiki/Extras/Contributors If you have any questions, feel free to drop me an email. Thankyou.I am currently away, so will continue with registration at the weekend. OK, I have now created an account, and await your sponsorship :) Perhaps the naming could/should be: emacs-muse, emacs-muse-common, emacs-muse-xemacs, etc? Well we need some kind of Fedora policy on how to package elisp IMHO. Some time ago tagoh suggested to me the idea of doing it the Debian way, ie bytecompiling at install time for the installed emacsen. Assuming emacs 22 doesn't get released soon, we may well see a emacs22 package in Extras soon too. In response to comment #15: I sponsored you on 2006-03-19, pinged you on 2006-03-31 via email when you said hopefully you would import over the weekend. Do you expect to have time soon? If you are too busy perhaps it would be better to drop my sponsorship and let someone else with more time step forward for this package? In response to comment #16: Yeah, some policy on elisp files would be nice. I don't like 'emacs-muse-xemacs' as a package name, thats just plain confusing. In the absense of policy, I think it's fine for this to be emacs-muse and xemacs-muse. Several other packages use that scheme. Apologies - I have been travelling madly the past month, and have returned proper this evening. I will complete the muse submission tomorrow. OK - I have submitted the package, updated the owners.list file and requested CVS branches - can't do more until that happens. However, and related to comment #16, the package naming issue oddity came up again. To recap, the SRPM is called muse-version.srpm, and it generates: muse-version.rpm emacs-muse-version.noarch.rpm emacs-muse-el-version.noarch.rpm xemacs-muse-version.noarch.rpm xemacs-muse-el-version.noarch.rpm So, the question is, what should I have used for the module name in owners.list ? I entered "emacs-muse", but on reflection I perhaps should have entered "muse". The issue then is that the module name no longer has the emacs- or xemacs- part in it, as required by the fedora-extras guidelines, even though (some of) the rpms do. In short, the fedora-extras guidelines fail for "addon" packages for sources which generate add-ons for two different programs (in this case emacs and xemacs). Thoughts? I think we should just call the CVS directory and SRPM "emacs-muse". Any other opinions? Jonathan, your CVSSyncNeeded request "FC-5 FC-6 (devel) muse" is improper. There is FC-6 branch, and devel is implicit from import, so the only branch you really needed was FC-5. Warren - apologies for the incorrect CVS sync request - I am still learning :). Regarding the CVS directory and SRPM name - the problems with calling it emacs-muse are: 1) It doesn't match the source tarball name (as is required by FE guidelines) 2) emacs-muse is confusing when you consider it also builds xemacs addon packages. (emacs-muse is actually the name I originally chose until people requested xemacs packages be built too) Problem is, I could come up with problems for any naming scheme. Basically, the FE guidelines are impossible to comply with in this case. The same issue is faced by any package which builds addon elisp packages for both emacs and xemacs from the same source.... Build currently fails for devel for which FE has a beta version of xemacs (unwise, I think) - reported upstream: https://gna.org/bugs/index.php?func=detailitem&item_id=4682 Build log: http://buildsys.fedoraproject.org/logs/fedora-development-extras/8125-muse-3.02.6b-4.fc6/noarch/build.log Once the FC5 CVS branch is made, I'll request a build of the package for that, where I know it builds. I think the module name should just be 'muse' - other packages do it this way (see 'mew') - it's the name of the base source tar - there is no confusion about it being for only emacs/xemacs thoughts? IMHO we should move to a policy of all elisp packages being named emacs-<package>. This is in line with the naming for libraries of other interpreted languages like python, perl and I'm planning to follow this for ghc (Haskell) libraries too. http://fedoraproject.org/wiki/Packaging/NamingGuidelines#head-e865dfbf5ffb4156a1bdf299ace96f48af903a7a Probably xemacs-<package>, etc is a good convention for XEmacs packages. Traditionally we suffixed with -xemacs in Core, and hence the naming of the elisp packages in Extras that formerly were part of Core. Ideally those packages should be renamed to follow the naming policy if possible. Hi Jens - this is what I have tried to do. However, the BIG problem is that the emacs- and xemacs- packages are inevitably built from the same spec and tarball, which has a different name (no prefix), and so the module name is different. Joe User then has a problem with emacs-foo, but then can't find emacs-foo in bugzilla, because the module is called foo. We can't rename the module to emacs-foo because then Joe has a problem with xemacs-foo and still can't find the right module. We can't rename the module xemacs-foo, because Joe has a problem with xemacs-foo. etc. etc. In short, what you propose (and what I've tried to do) isn't possible because the same source provides extensions for *two* "interpreters" (emacs and xemacs) and hence there is a naming conflict. Worse, emacs is in core, xemacs is now in extras. To achieve what you propose would in the end require having *two* modules in core, two spec files, and twice the work :) No it wouldn't. There is no real problem for a single source RPM of any name to spit out binary packages of any names. I think we need to be promoting consistency in package namespaces. I propose that we bring this to the next Fedora Extras Steering comittee meeting for discussion. Meanwhile if anyone else has opinions please speak up. Hi Warren - I agree, there's no real problem, technically - in fact, that's what I've done. I'm just worried from the user perspective. Perhaps I am worrying too much though, given that the user would have to install muse and emacs-muse (and/or xemacs-muse) and so should know to look for a module called muse and not emacs-muse. I would like to add though, that I think the approach used here (muse, emacs-muse, xemacs-muse from a muse srcrpm) is much more preferable to having muse muse-emacs and muse-xemacs which is what the mew model would give. Prepending the interpreter is following the current guidelines. Can we ponder the bytecompiling at the install time before doing this? - Does someone wants to spam bugs when one imports a flavor of emacsen like emacs22, SXEmacs etc etc, and all elisp packages needs to be reworked then? It sounds like the unnecessary work to me. changing the package name to emacs-<elisp name> should be still valid idea though, I suspect that we don't need an extra work to add subpackages for a flavor of emacsen at all. Could someone explain me the significant reason why we have to provide the bytecompiled packages for each flavor of emacsen rather than bytecompiling at the install time? - We didn't just need to care of others when we didn't work the community together, because we didn't have any plans to ship other emacsen any more. but now, we have a chance to do it. current approach isn't comfortable to do it and it imposes a burden on all elisp maintainers. I'd propose this again. TIA, What if I install emacs, then some packages, then xemacs? Some thought needs to do into how this would work. Triggers? The base package for each emacs flavor could byte-compile everything in sight when it is installed and then each subpackage could compile itself for each installed emaacs flavor. But those packages would have to %ghost a lot of files so they properly uninstall all of the compiled versions that they might not even know about. And the issue of compatibility between packages and the various emacs flavors would make things terribly complicated. If we use the same things what Debian does, we don't rely on the trigger at all, which may mess up ;) For the reference, http://www.debian.org/doc/packaging-manuals/debian-emacs-policy especially see section 6. emacsen-common provides a facility to do byte-compile for every flavor of emacsen. What the elisp packages needs to do is, just to call emacs-package-install/emacs-package-remove in %post/%postun. and emacs-install/emacs-remove is for emacsen itself and to byte-compile all elisp available on system. it's useful when additional emacsen is installed on system and noone needs to install another package to use on it nor noone even needs to build another subpackage for that. So I don't think any packages need to do %ghost. packagers just needs to prepare the install/remove script and put it under /usr/lib/emacsen-common/packages/{install,remove}/, also just include all necessary elisp packages in rpm. that's it. you will miss the feature that queries the byte-compiled elisp files to rpm to know which package owns it though, I don't think it's an issue. For the compatibility, you can just exclude the incompatible flavor of emacsen in install script. Debian packages ordinarily does it as needed. HTH (Removing myself from Cc, three mails of every change here is a bit much...) FWIW, I'm not a fan of the byte-compile-in-%post idea. For example: no other packages (eg. python) do that either, it will cause problems with %{_netsharedpath} and read-only /usr/share mounts, and local *Emacs configurations may affect the byte-compilation possibly resulting in hard to debug issues. Are there any yet-another python implementation? someone may still wants to use older release of python though, it sounds to me like it's a little different case, and even if someone does support byte-compiling installation for python, it may be less worth efforts. For %{_netsharedpath} and read-only /usr/share mounts, it could just stops to do byte-compiling if installation path is included in %{_netsharedpath} since rpm won't do anything. so it should be general issue but not specific issue. or can you explain me much more details that is likely case? Also, you will have to do byte-compile with --no-init-file --no-site-file, of course. Byte compiling in %post is an interesting idea, but I think it doesn't really survive a cost-benefit analysis. Getting the infrastructure right for that would be a big job. Plus, if I understand correctly, we may miss build fails and start shipping broken packages, since I suspect the build system won't detect byte compilation fails, since it builds, but doesn't install the package. One could imagine installing a new emacsen package, which would trigger byte compiling of a number of installed packages which, since the elisp api isn't stable, could break. Messy. Or do I have the wrong end of the stick? it may be a little higher cost, right. so we could just borrow emacsen-common package from Debian, which is working well. For detecting fails at the build time, don't you do any testing when you put newer package? as one sometimes wrongly put a broken package that just passed compiler-wise false detection, putting packages without testing is always dangerous. you could still find any issues more with self-installation testing before pushing packages into the build queue. Well, if the elisp api isn't stable, problems should appears with/without add-on elisp, even with/without this idea. then that flavor of emacsen itself will be broken. it's irrelevant to this idea. Of course I test building of the packages using mock. However, I can't test *installation* on all platforms, as I simply don't have access to them all. What you're proposing relies upon elisp compilation at install time, not package build time. Mock goes a long way to testing package building, but not package installation. The elisp api is well understood to be inconsistent between flavours, and unstable between versions within a flavour. This isn't a problem, as packages get updated as the api changes. But, your proposal would have packages automatically triggered to be byte compiled for all emacs versions as they're installed, irrespective of whether the package has been updated for the relevant api... this will inevitably lead to broken packages installed on users machines, UNLESS there is a way to control what versions of emacs the package is byte compiled for on installation/triggering. That may be possible? Well, I'm not blaming you on your packaging process. I'm sorry if you feel that way. I mean you could just package your elisp as noarch package, and there shouldn't be any different between architectures. if that's a problem, possibly it should appears at the build time for a flavor of that emacsen. so I suppose you can assume that the installation on all archs should be ok if you can install your elisp successfully on your box. or is this wrong assumption? Well, I'm not sure if I understood correctly your comment on elisp api though, for instance, if your package, foo is updated, emacsen-common is just going to byte-compile foo only, or another one if your install script invokes one - actually in Debian, apel install script invokes flim install script so that it depends on flim and sometimes broke without re-byte-compiling it, but anyway - for all flavors of emacsen since the byte-compiled elisp files for foo is out-of-date. and if only xemacs package is updated, emacsen-common is going to remove all byte-compiled files for xemacs and byte-compile all elisp packages for xemacs again. it won't touch other flavors of emacsen. so I'm not sure what's "irrespective". for good example above apel install script, here is quote: # recompile flim pkg=flim if [ -d /usr/share/${FLAVOR}/site-lisp/${pkg} ]; then if [ -f /usr/lib/emacsen-common/packages/install/${pkg} ]: then /usr/lib/emacsen-common/packages/remove/${pkg} ${FLAVOR} /usr/lib/emacsen-common/packages/install/${pkg} ${FLAVOR} fi fi Those is what described in apel install script that put as /usr/lib/emacsen-common/packages/install/apel on the debian box. and ${FLAVOR} is to know which flavors of emacsen - including versions of emacsen - such as emacs21 and xemacs21 install script is going to be invoked for. Is it clear? doh, *flim* depends on apel. well, if this is the case, only the way without harcode like this is, to rely on %trigger. Also emacsen-common is going to re-byte-compile apel if flim is updated or installed, in above case, though. Removing fedora-extras-list, because we should have got the attention of people who care about emacs sub-packages by now. (In reply to comment #32) > Are there any yet-another python implementation? I don't know, but some people do want different versions (newer, older, whatever) installed. Python aside, another example are kernel module packages. Yes, it is acceptable to compile on the fly or %post or something in some folks' opinion (for example DKMS does that unless I'm mistaken), but there is strong opposition to that from others. > and even if someone does support byte-compiling installation for python, > it may be less worth efforts. Less than for various Emacsen? I fail to see why. > For %{_netsharedpath} and read-only /usr/share mounts, it could just stops to > do byte-compiling if installation path is included in %{_netsharedpath} since > rpm won't do anything. Yes, but that kind of defeats the idea of getting stuff byte compiled for whatever Emacsen are installed on that particular box. On a side note, there have been lots of reports over time on xemacs-beta about Debian's setup being broken and resulting in for example XEmacs somehow getting *.elc bytecompiled by GNU Emacs in its load path. That will obviously wreak havoc. OTOH my gut feeling is that the reports are less frequent nowadays so it's possible that the Debian folks have got it fixed. My feeling is that, while what Akira is suggesting has merit, what it's ultimately an attempt to do is to bend rpm to deal with installation from source (.el) rather than binary.. it's not so dissimilar to gentoos ebuilds etc. It really seems like trying to get rpm to do things it wasn't designed to do. I'm in favour of keeping things simple, working with binary packages, and not aiming for the canonical solution. Pragmatically though, we can't move to using a emacsen-common like approach until someone steps forward to do the necessary work, and I can't really see that happening unless the solution is applicable to more than emacs lisp packages. [On a tangent though, if there was a mechanism for installing an rpm of source files (be they .el, python modules, C, or whaterver) and having builds triggered by installation of other packages, that'd be a really nice way to install a kernel module package that autobuilt every time the kernel was updated. However, again this is clearly a different model than rpm was designed for as it's based on sources management, not binaries. I suppose Conary might have capability akin to this] There are several questions here, and I'm not sure this bug is the best place to discuss this, but here are my thoughts: - Should elisp packages have their own namespace? (ie, like perl- packages) I don't know that this is worth it... how many elisp packages are out there that aren't already shipped with emacs/xemacs? If I am using repoquery right, not many: emacs: apel-0:10.6-8.fc5.noarch bigloo-emacs-0:2.8a-1.20060322.fc5.i386 emacs-auctex-0:11.82-3.fc5.noarch mew-0:4.2-2.fc5.i386 ruby-mode-0:1.8.4-3.2.i386 uim-el-0:1.0.1-2.fc5.i386 w3m-el-0:1.4.4-2.fc5.i386 xemacs: bigloo-xemacs-0:2.8a-1.20060322.fc5.i386 mew-xemacs-0:4.2-2.fc5.i386 w3m-el-xemacs-0:1.4.4-2.fc5.i386 - Should we byte compile at install time instead of build time? PRO: one package works for both xemacs/emacs. PRO: byte compiled files exactly match installed emacs/xemacs. CON: increase rpm install time. CON: if disk space runs out bad things happen CON: adds complexity CON: .elc files won't be verifyable via rpm In any case we can bring these questions to FESCO... but for this package I think we should just use the base package name and ship the compiled files, it can be changed if the policy is decided to change (as indeed other packages will need to be changed). Can we move this discussion to the extras list? I have moved the namespace discussion to the FE list. However, I don't feel I understand the build in %post proposal well enough to properly convey it to the list - Akira, if you have the time and energy, I think it's worth bringing that up on FE list as well. (In reply to comment #40) > Less than for various Emacsen? I fail to see why. Well, in the release cycle POV. newer release of emacs isn't seen a long time. I suppose there may be strong request to use the latest emacs but may wants to keep the stable version together. but yes, there may be more or less such requirements on others as well. > Yes, but that kind of defeats the idea of getting stuff byte compiled for > whatever Emacsen are installed on that particular box. > > On a side note, there have been lots of reports over time on xemacs-beta about > Debian's setup being broken and resulting in for example XEmacs somehow getting > *.elc bytecompiled by GNU Emacs in its load path. That will obviously wreak > havoc. OTOH my gut feeling is that the reports are less frequent nowadays so > it's possible that the Debian folks have got it fixed. Ouch. Though I haven't seen any xemacs-beta package for Debian yet - at least in the official tree - it may be because it just doesn't follow the emacsen-common-way. (In reply to comment #41) > My feeling is that, while what Akira is suggesting has merit, what it's > ultimately an attempt to do is to bend rpm to deal with installation from source > (.el) rather than binary.. it's not so dissimilar to gentoos ebuilds etc. It > really seems like trying to get rpm to do things it wasn't designed to do. I'm > in favour of keeping things simple, working with binary packages, and not aiming > for the canonical solution. it's sensible. discussing something without the real implementation is little messy. so I'll try to do it when I have a time, and let's continue to discuss against it then. Sorry to interrupt your package contribution. (In reply to comment #44) > Ouch. Though I haven't seen any xemacs-beta package for Debian yet Sorry for being unclear, by "xemacs-beta" I meant the xemacs-beta mailing list. OK - packages have now been built and are in the repo for FC5. devel packages not yet buildable due to upstream problem between muse and the beta version of xemacs that devel has moved to. According to the instructions, I should now close this bug as NEXTRELEASE, but that doesn't seem to be within my gift - perhaps Kevin can do that. Thanks to you all for your help and suggestions getting this through the review procedure. Change summary for tracking purposes. |