From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: [ELPA] New package xeft.el Date: Thu, 12 Jan 2023 23:51:30 -0500 Message-ID: References: <64A01ADD-E757-40F5-A5C3-518BB8BE9A41@gmail.com> <659E0780-5694-4B43-9845-AF1C0E2F7ECE@gmail.com> Reply-To: rms@gnu.org Content-Type: text/plain; charset=Utf-8 Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="36252"; mail-complaints-to="usenet@ciao.gmane.io" Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Yuan Fu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Jan 13 05:52:30 2023 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pGC3J-0008zx-G9 for ged-emacs-devel@m.gmane-mx.org; Fri, 13 Jan 2023 05:52:29 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pGC2P-000221-JR; Thu, 12 Jan 2023 23:51:33 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pGC2N-00021o-Vf for emacs-devel@gnu.org; Thu, 12 Jan 2023 23:51:32 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pGC2M-0007er-T9; Thu, 12 Jan 2023 23:51:30 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=Date:References:Subject:In-Reply-To:To:From: mime-version; bh=41bIDVrLXHxvpny0zxtaQXNw9piS4k0Muv3g9F5IT5Q=; b=PSs34USODRfI RyiMvkGSQ5Q/Tka7ikAeF7kbeJHrFiSx1W94bQt35AgFdU8SO2ByF3Y9AMPthyFHP6CvAVg/1eLDi qMKElvHx8d87964oQ5ec1RJIe6p7092UFqF4EAJG1cRPlqQaL4Ad6ROKhEWqh4UNAzejS2hxbvEqs Tebq1aeaT4n3xH+2f41mRBFqwwQCZy3+KtegMBKmVsDWebZxeHwTkNMptRBaTH2TSd5VbzKG2/W9F R364UUS7dI1HWBaBC0+NxsVls/yPH+aQJu6R3K6+lEFlHVA+g6YWXQYLu5n2210EnI2Hb0H87SXKo 9ae5IqtcT2KeUnGyWuz3Mw==; Original-Received: from rms by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1pGC2M-0002wy-Ew; Thu, 12 Jan 2023 23:51:30 -0500 In-Reply-To: (message from Yuan Fu on Tue, 10 Jan 2023 02:57:14 -0800) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:302389 Archived-At: [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] It appears we are discussing a proposal that we host compiled native code for users to download. We should not do that. There is nothing wrong with distributing binaries of GNU packages alongside their source code. For instance, packaged GNU systems usually offer binary downloads, and that includes approved free distros. However, the GNU Project's policy is that this is _not our job_. We try to avoid releasing binary forms of packages except when there is a special need. (For instance, a compiled GCC for platforms that have no C compiler.) This is for simple practical reasons that are very important: * It would mean additional responsibility for the maintainers, who generally have as much as they want to handle. * It would take up maintainers' time, and the other contributors' time. Even supporting binaries build and uploaded by other volunteers (assuming those were not halping the package's development in other ways) would take work for the maintainers. * It would be an opportunity for error. * If we did it for one platform, we would face pressure to support others. "Please let me upload the code for XYZ!" Thus. we do not (and should not) distribute the executable `emacs' compiled for widely used platforms -- even though you can't run Emacs at all without that. We leave this helpful activity _to others_. How does native-compiled Emacs Lisp code compare with native-compiled src/*.c? The main difference is that native-compiled Emacs Lisp code is optional -- you don't _need_ it to run Emacs. This means that the upside of distributing that particular compiled code is less -- but the downside is the same. -- Dr Richard Stallman (https://stallman.org) Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)