Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 43331 - most app-emacs ebuilds should be platform independent
Summary: most app-emacs ebuilds should be platform independent
Status: RESOLVED INVALID
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All All
: High enhancement (vote)
Assignee: Emacs project
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-02-29 15:56 UTC by John Steele Scott
Modified: 2004-04-02 20:12 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description John Steele Scott 2004-02-29 15:56:52 UTC
It seems to me that it would be very rare for an elisp package to be broken on one arch but work on the others. However, as far as I can tell, all the app-emacs ebuilds use the KEYWORDS variable in the regular fashion. This creates unnecessary duplication of work as a package must be tested on each architecture before it can be flagged stable.

I propose that all the builds which use the elisp class should replace the KEYWORDS variable with ELISP_STABLE, which could be true or false. According to this value, elisp.eclass would then set KEYWORDS to be stable on all archs, or unstable on all archs. In the case where this scheme is inappropriate, the ebuild could just set KEYWORDS itself, and leave ELISP_STABLE unset.

Does this seem like a good idea to anyone apart from me?
Comment 1 Jeremy Maitin-Shepard 2004-02-29 18:52:13 UTC
While it is true that that many or most of the emacs lisp packages will work on all platforms on which emacs does, some packages may depend on external programs, or have some other issue, and so it has been decided that packages should not be marked even in ~arch if they have not been tested even once on that platform.  If you have tested an elisp package on some non-x86 platform, please tell us and we will mark it at least ~arch.
Comment 2 John Steele Scott 2004-04-02 20:12:12 UTC
Thanks Jeremy,

No reason to leave this bug open.