Re: emacs.app_9.0pre2-1_i386.changes REJECTED

["Gürkan Sengün" <gurkan-2Ut+nkrRcIBypLqBFPtG/w@public.gmane.org>]

Hello,

Adrian Robert has been working hard on the Emacs.app port for systems with
AppKit and FoundationKit:
http://emacs-app.sourceforge.net/

For the curious and history:
1992 18.x http://www.linuks.mine.nu/openstep/emacs.png
2005 23.x http://gnu.ethz.ch/emacs.app.png

I am working on a Debian package and a http://livecd.gnustep.org to
get this graphical version of emacs.

Any help/suggestions on getting this into emacs mainstream source is welcome.
Please read the following mails for details.

Debian Emacs developers: i fully agree with Jörg here. is there any plans
for emacs 23.x based packages? how to split/where to put the stuff that
doesn't need be built for an arch?

It will be so great to have Emacs.app (with GNUstep) on Windows one day:
http://www.phys.ethz.ch/~sengun/GNUstep.Win.Gorm.gif

Cheers,
Gürkan

>> Hi Adrian,
>> 
>> for your info for now... I will keep on working on the packaging...
>> 
>> did you ever talk to the gnu emacs guys? if you're on irc, come  #emacs on
>> irc.gnu.org ... i think it would be good we take this to the emacs  and 
>> debian-devel
>> mailinglists....
> 
> Hi,
> 
> Regarding GNU Emacs, I have been in communication on the mailing list  there 
> and believe the stars are still aligned for this port to be  accepted into 
> mainline CVS sometime within the next six months.   However this will be the 
> unicode-2 (to-be-emacs-23) branch only,  unless someone wants to put some 
> effort into getting non-ascii  rendering working under emacs-22.
> 
> The 22/23 issue also relates to getting into Debian.  Currently  Debian seems 
> to have "emacs21" and "emacs-snapshot".  Since emacs- snapshot is basically 
> emacs-22, I doubt it is sharing very much lisp  with emacs21 -- it probably 
> puts 70 MB under /usr/share/emacs/22.0.50  which nothing else uses, and uses 
> little or nothing out of emacsen- common.   Given this status, perhaps the 
> debian-emacs people would be  satisfied by simply building Emacs.app to put 
> its lisp under /usr/ share/emacs/23.0.0.  (That way it could theoretically 
> share with  emacs-23 once emacs-snapshot moves to that version sometime in  
> 2006.)  I think we should bring this out on the debian-emacs list as  you 
> suggested.. if you send a msg there and cc me, I can answer..
> 
> thanks,
> Adrian
> 
>> ---------- Forwarded message ----------
>> Date: 2005-11-30 00:11:59 +0100
>>  From: Joerg Jaspert <ftpmaster-8fiUuRrzOP0dnm+yROfE0A@public.gmane.org>
>> Subject: emacs.app_9.0pre2-1_i386.changes REJECTED
>> 
>> Hi Maintainer,
>> 
>> rejected, this packaging attempt is broken, sorry.
>> 
>> To start with something good: In the longterm you may be able to get
>> this into Debian. But that needs a lot of changes to the packag[e| ing].
>> 
>> - You have *one* big .deb for this. Which includes all stuff that
>>    per definition needs to go into an Arch: all package.
>>    This makes 28*10 MB of useless duplication in our archive/on the
>>    mirrors.
>> 
>> - The wole package is a running FHS (and as such policy) violation.  It 
>> seems
>>    to ignore that there is usr/share for architecture independent  stuff.
>>    Oh wait, yes, thats a Gnustep problem - but there it needs to be  fixed 
>> too.
>> 
>> - You duplicate the whole emacs. Thats not good. There is nothing  to say 
>> against
>>    a new UI of a program, but the duplication has to be avoided. Im  sure 
>> that 99.9% of
>>    the includes lisp files for example dont need anything special to  run 
>> with this
>>    new UI. Please coordinate with the emacs maintainer to share as  much 
>> pieces as
>>    possible. The ideal solution would be if it builds out of the  same source
>>    (with a patch applied at built time or so), but even if not -  your 
>> package
>>    should only include the minimum needed, depending on the other emacs
>>    packages for the rest of the files.
>> 
>> Feel free to take this to the -devel or the -emacs list if you want  more
>> discussion of this.