From: Mamoru KOMACHI <usata@gentoo.org>
To: gentoo-dev@gentoo.org
Subject: [gentoo-dev] Re: (emacs) proposed site-lisp and byte-compilation improvements
Date: Tue, 18 Nov 2003 00:40:02 +0900 [thread overview]
Message-ID: <86ptfrgg19.wl%usata@gentoo.org> (raw)
In-Reply-To: <87r807c2it.fsf@killr.ath.cx>
Hi,
At Sun, 16 Nov 2003 17:33:14 -0600,
Matthew Kennedy wrote:
> * Firstly, please review this:
>
> http://dev.gentoo.org/~mkennedy/emacs/site-gentoo.el-rfc.txt
I'll second it. It will also solve http://bugs.gentoo.org/show_bug.cgi?id=10742
> * Install elisp source in such a way that global recompilation is
> possible.
> I suggest we provide a way to recompile all .el files for elisp add-on
> packages (typically from the app-emacs/ category, but also from
> ebuilds supporting the emacs USE flag). This mechanism should be
> called whenever a new emacs upgrade is performed.
I think the feature what you suggest here is not emacs specific but
global. For example, when people bumped openssl version 0.9.6 to 0.9.7
we saw many breakages and needed to run revdep-rebuild by hand.
However, if we had a variable in ebuild that tells Portage "all
the ebuilds that depend on me should be compiled again after emerge"
we wouldn't come across the problem. If this feature is implemented
into Portage we will have no problem not only with ebuilds in
app-emacs but also with other ebuilds supporting emacs USE flag
(because such ebuilds depend on virtual/emacs).
> * Your Thoughts Here...
I wonder why we don't have xemacs herd. Some of the bugs in bugzilla
were assigned to emacs@g.o after the alias was created, but I think
xemacs herd should be created and these bugs will be assigned to that
herd. There are two reasons for it. First, as I see from ChangeLogs in
app-xemacs category, xemacs packages are maintained by agriffis,
rendhalver and rac (they don't commit to app-emacs and those who
commit to app-emacs don't touch app-xemacs). Second, FSF Emacs and
XEmacs have different packaging policy and should be considered
separetely (I'm not using XEmacs, so I should ask XEmacs people before
I do any changes if it is assigned to emacs herd). We could have
meta-emacs herd to which both emacs and xemacs herd belong, but that
will be a different issue we might consider after creating xemacs
herd.
Any comments?
--
Mamoru KOMACHI <usata@gentoo.org>
http://www.gentoo.org/~usata/
--
gentoo-dev@gentoo.org mailing list
prev parent reply other threads:[~2003-11-17 15:40 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-11-16 23:33 [gentoo-dev] (emacs) proposed site-lisp and byte-compilation improvements Matthew Kennedy
2003-11-17 0:29 ` Spider
2003-11-17 1:26 ` Jeremy Maitin-Shepard
2003-11-17 15:40 ` Mamoru KOMACHI [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=86ptfrgg19.wl%usata@gentoo.org \
--to=usata@gentoo.org \
--cc=gentoo-dev@gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox