Bug 181404

Summary: Review Request: emacs-common-muse
Product: [Fedora] Fedora Reporter: Jonathan Underwood <jonathan.underwood>
Component: Package ReviewAssignee: Kevin Fenzi <kevin>
Status: CLOSED NEXTRELEASE QA Contact: Fedora Package Reviews List <fedora-package-review>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: 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
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-1.jgu.src.rpm
Description: 
Emacs Muse is an authoring and publishing environment for Emacs. It simplifies
the process of writings documents and publishing them to various output
formats. Muse uses a very simple Wiki-like format as input.

Muse can publish to the following formats.

    * Blosxom
    * DocBook
    * HTML
    * LaTeX
    * PDF
    * Texinfo
    * XHTML
    * XML

Comment 1 Jonathan Underwood 2006-02-13 20:47:35 UTC
Should have mentioned: This is my first package for FE, and I require a sponsor.

Comment 2 Neal Becker 2006-02-14 02:14:20 UTC
How about xemacs? 

Comment 3 Jonathan Underwood 2006-02-14 14:03:11 UTC
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

Comment 4 Jonathan Underwood 2006-02-14 17:43:02 UTC
Once this package is in FE, I will create a sister xemacs-muse package if it is
felt necessary.

Comment 5 Kevin Fenzi 2006-02-16 02:46:17 UTC
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. 

Comment 6 Jonathan Underwood 2006-02-16 15:49:28 UTC
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.

Comment 7 Ville Skyttä 2006-02-16 17:38:48 UTC
auctex is not a good example; it is shipped for XEmacs in the xemacs-sumo package.

Comment 8 Jonathan Underwood 2006-02-27 22:10:07 UTC
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 :)

Comment 9 Kevin Fenzi 2006-03-05 19:56:20 UTC
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.


Comment 10 Jonathan Underwood 2006-03-05 22:58:20 UTC
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.

Comment 11 Kevin Fenzi 2006-03-05 23:43:46 UTC
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?



Comment 12 Jonathan Underwood 2006-03-06 10:39:42 UTC
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.

Comment 13 Kevin Fenzi 2006-03-07 04:23:28 UTC
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. 

Comment 14 Jonathan Underwood 2006-03-07 10:53:18 UTC
Thankyou.I am currently away, so will continue with registration at the 
weekend. 

Comment 15 Jonathan Underwood 2006-03-19 13:06:46 UTC
OK, I have now created an account, and await your sponsorship :)

Comment 16 Jens Petersen 2006-04-18 09:32:31 UTC
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.

Comment 17 Kevin Fenzi 2006-04-20 20:23:14 UTC
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. 

Comment 18 Jonathan Underwood 2006-04-22 23:11:13 UTC
Apologies - I have been travelling madly the past month, and have returned
proper this evening. I will complete the muse submission tomorrow.

Comment 19 Jonathan Underwood 2006-04-23 17:38:04 UTC
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?

Comment 20 Warren Togami 2006-04-23 17:56:42 UTC
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.

Comment 21 Jonathan Underwood 2006-04-23 18:08:18 UTC
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....



Comment 22 Jonathan Underwood 2006-04-23 18:12:29 UTC
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.

Comment 23 Kevin Fenzi 2006-04-23 18:15:53 UTC
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?

Comment 24 Jens Petersen 2006-04-24 11:48:06 UTC
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.


Comment 25 Jonathan Underwood 2006-04-24 12:23:42 UTC
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 :)

Comment 26 Warren Togami 2006-04-24 15:19:31 UTC
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.

Comment 27 Jonathan Underwood 2006-04-24 16:14:38 UTC
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.

Comment 28 Akira TAGOH 2006-04-24 23:31:06 UTC
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,

Comment 29 Jason Tibbitts 2006-04-25 02:10:17 UTC
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.

Comment 30 Akira TAGOH 2006-04-25 03:13:58 UTC
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

Comment 31 Ville Skyttä 2006-04-25 05:33:25 UTC
(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.

Comment 32 Akira TAGOH 2006-04-25 06:48:45 UTC
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.

Comment 33 Jonathan Underwood 2006-04-25 09:34:11 UTC
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?

Comment 34 Akira TAGOH 2006-04-25 09:53:33 UTC
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.

Comment 35 Jonathan Underwood 2006-04-25 10:33:13 UTC
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?

Comment 36 Akira TAGOH 2006-04-25 11:52:49 UTC
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?

Comment 37 Akira TAGOH 2006-04-25 11:57:58 UTC
doh, *flim* depends on apel. well, if this is the case, only the way without
harcode like this is, to rely on %trigger.


Comment 38 Akira TAGOH 2006-04-25 12:26:15 UTC
Also emacsen-common is going to re-byte-compile apel if flim is updated or
installed, in above case, though.

Comment 39 Warren Togami 2006-04-25 15:17:39 UTC
Removing fedora-extras-list, because we should have got the attention of people
who care about emacs sub-packages by now.


Comment 40 Ville Skyttä 2006-04-25 17:44:30 UTC
(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.

Comment 41 Jonathan Underwood 2006-04-25 18:03:59 UTC
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]

Comment 42 Kevin Fenzi 2006-04-25 18:30:40 UTC
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?


Comment 43 Jonathan Underwood 2006-04-25 21:02:59 UTC
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.

Comment 44 Akira TAGOH 2006-04-26 01:38:36 UTC
(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.

Comment 45 Akira TAGOH 2006-04-26 01:45:49 UTC
(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.


Comment 46 Ville Skyttä 2006-04-26 08:32:50 UTC
(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.

Comment 47 Jonathan Underwood 2006-04-26 14:10:20 UTC
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.

Comment 48 Christian Iseli 2007-01-04 19:46:05 UTC
Change summary for tracking purposes.