[Bug 181404] Review Request: emacs-muse
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: emacs-muse https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181404 [EMAIL PROTECTED] changed: What|Removed |Added Status|ASSIGNED|CLOSED Resolution||NEXTRELEASE -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug, or are watching the QA contact. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 181404] Review Request: emacs-muse
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: emacs-muse https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181404 --- Additional Comments From [EMAIL PROTECTED] 2006-04-26 10:10 EST --- 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. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug, or are watching the QA contact. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 181404] Review Request: emacs-muse
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: emacs-muse https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181404 --- Additional Comments From [EMAIL PROTECTED] 2006-04-26 04:32 EST --- (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 [EMAIL PROTECTED] mailing list. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug, or are watching the QA contact. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 181404] Review Request: emacs-muse
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: emacs-muse https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181404 --- Additional Comments From [EMAIL PROTECTED] 2006-04-25 21:45 EST --- (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. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug, or are watching the QA contact. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 181404] Review Request: emacs-muse
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: emacs-muse https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181404 --- Additional Comments From [EMAIL PROTECTED] 2006-04-25 21:38 EST --- (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. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug, or are watching the QA contact. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 181404] Review Request: emacs-muse
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: emacs-muse https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181404 --- Additional Comments From [EMAIL PROTECTED] 2006-04-25 17:02 EST --- 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. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug, or are watching the QA contact. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 181404] Review Request: emacs-muse
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: emacs-muse https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181404 --- Additional Comments From [EMAIL PROTECTED] 2006-04-25 14:30 EST --- 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? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug, or are watching the QA contact. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 181404] Review Request: emacs-muse
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: emacs-muse https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181404 --- Additional Comments From [EMAIL PROTECTED] 2006-04-25 14:03 EST --- 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] -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug, or are watching the QA contact. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 181404] Review Request: emacs-muse
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.
Summary: Review Request: emacs-muse
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181404
--- Additional Comments From [EMAIL PROTECTED] 2006-04-25 13:44 EST ---
(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.
--
Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the QA contact for the bug, or are watching the QA contact.
___
Fedora-package-review mailing list
Fedora-package-review@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 181404] Review Request: emacs-muse
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: emacs-muse https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181404 [EMAIL PROTECTED] changed: What|Removed |Added CC|fedora-extras- | |[EMAIL PROTECTED] | --- Additional Comments From [EMAIL PROTECTED] 2006-04-25 11:17 EST --- Removing fedora-extras-list, because we should have got the attention of people who care about emacs sub-packages by now. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug, or are watching the QA contact. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 181404] Review Request: emacs-muse
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: emacs-muse https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181404 --- Additional Comments From [EMAIL PROTECTED] 2006-04-25 08:26 EST --- Also emacsen-common is going to re-byte-compile apel if flim is updated or installed, in above case, though. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug, or are watching the QA contact. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 181404] Review Request: emacs-muse
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: emacs-muse https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181404 --- Additional Comments From [EMAIL PROTECTED] 2006-04-25 07:57 EST --- doh, *flim* depends on apel. well, if this is the case, only the way without harcode like this is, to rely on %trigger. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug, or are watching the QA contact. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 181404] Review Request: emacs-muse
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.
Summary: Review Request: emacs-muse
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181404
--- Additional Comments From [EMAIL PROTECTED] 2006-04-25 07:52 EST ---
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?
--
Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the QA contact for the bug, or are watching the QA contact.
___
Fedora-package-review mailing list
Fedora-package-review@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 181404] Review Request: emacs-muse
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: emacs-muse https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181404 --- Additional Comments From [EMAIL PROTECTED] 2006-04-25 06:33 EST --- 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? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug, or are watching the QA contact. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 181404] Review Request: emacs-muse
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: emacs-muse https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181404 --- Additional Comments From [EMAIL PROTECTED] 2006-04-25 05:53 EST --- 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. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug, or are watching the QA contact. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 181404] Review Request: emacs-muse
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: emacs-muse https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181404 --- Additional Comments From [EMAIL PROTECTED] 2006-04-25 05:34 EST --- 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? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug, or are watching the QA contact. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 181404] Review Request: emacs-muse
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.
Summary: Review Request: emacs-muse
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181404
--- Additional Comments From [EMAIL PROTECTED] 2006-04-25 02:48 EST ---
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.
--
Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the QA contact for the bug, or are watching the QA contact.
___
Fedora-package-review mailing list
Fedora-package-review@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 181404] Review Request: emacs-muse
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.
Summary: Review Request: emacs-muse
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181404
[EMAIL PROTECTED] changed:
What|Removed |Added
CC|[EMAIL PROTECTED] |
--- Additional Comments From [EMAIL PROTECTED] 2006-04-25 01:33 EST ---
(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.
--
Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the QA contact for the bug, or are watching the QA contact.
___
Fedora-package-review mailing list
Fedora-package-review@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 181404] Review Request: emacs-muse
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.
Summary: Review Request: emacs-muse
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181404
--- Additional Comments From [EMAIL PROTECTED] 2006-04-24 23:13 EST ---
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
--
Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the QA contact for the bug, or are watching the QA contact.
___
Fedora-package-review mailing list
Fedora-package-review@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 181404] Review Request: emacs-muse
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: emacs-muse https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181404 --- Additional Comments From [EMAIL PROTECTED] 2006-04-24 22:10 EST --- 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. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug, or are watching the QA contact. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 181404] Review Request: emacs-muse
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: emacs-muse https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181404 --- Additional Comments From [EMAIL PROTECTED] 2006-04-24 19:31 EST --- 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- 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, -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug, or are watching the QA contact. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 181404] Review Request: emacs-muse
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: emacs-muse https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181404 --- Additional Comments From [EMAIL PROTECTED] 2006-04-24 12:14 EST --- 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. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug, or are watching the QA contact. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 181404] Review Request: emacs-muse
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: emacs-muse https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181404 [EMAIL PROTECTED] changed: What|Removed |Added CC||fedora-extras- ||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2006-04-24 11:19 EST --- 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. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug, or are watching the QA contact. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 181404] Review Request: emacs-muse
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: emacs-muse https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181404 --- Additional Comments From [EMAIL PROTECTED] 2006-04-24 08:23 EST --- 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 :) -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug, or are watching the QA contact. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 181404] Review Request: emacs-muse
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: emacs-muse https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181404 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED], ||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2006-04-24 07:48 EST --- IMHO we should move to a policy of all elisp packages being named emacs-. 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-, 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. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug, or are watching the QA contact. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 181404] Review Request: emacs-muse
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: emacs-muse https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181404 --- Additional Comments From [EMAIL PROTECTED] 2006-04-23 14:15 EST --- 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? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug, or are watching the QA contact. ___ Fedora-package-review mailing list [EMAIL PROTECTED] http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 181404] Review Request: emacs-muse
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: emacs-muse https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181404 --- Additional Comments From [EMAIL PROTECTED] 2006-04-23 14:12 EST --- 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. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug, or are watching the QA contact. ___ Fedora-package-review mailing list [EMAIL PROTECTED] http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 181404] Review Request: emacs-muse
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: emacs-muse https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181404 --- Additional Comments From [EMAIL PROTECTED] 2006-04-23 14:08 EST --- 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 -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug, or are watching the QA contact. ___ Fedora-package-review mailing list [EMAIL PROTECTED] http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 181404] Review Request: emacs-muse
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: emacs-muse https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181404 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2006-04-23 13:56 EST --- 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. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug, or are watching the QA contact. ___ Fedora-package-review mailing list [EMAIL PROTECTED] http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 181404] Review Request: emacs-muse
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: emacs-muse https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181404 --- Additional Comments From [EMAIL PROTECTED] 2006-04-23 13:38 EST --- 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? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug, or are watching the QA contact. ___ Fedora-package-review mailing list [EMAIL PROTECTED] http://www.redhat.com/mailman/listinfo/fedora-package-review
