From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christopher Allan Webber Subject: Re: Scope of support for Guix on other distros Date: Tue, 03 Oct 2017 05:38:42 -0500 Message-ID: <87fub03499.fsf@dustycloud.org> References: <1506935892.5574.15.camel@gmail.com> <9f2ed1cd-f7df-1a8f-8789-15bc53e46233@fastmail.net> <87tvzh5ylu.fsf@dustycloud.org> <20171002163817.bypveuihimo5akw2@abyayala> <87shf15qn0.fsf@dustycloud.org> <5583a861-8720-d03f-a56b-240d88bf04ea@platen-software.de> <87h8vgegdr.fsf@netris.org> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:45078) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dzKb6-00089D-QA for guix-devel@gnu.org; Tue, 03 Oct 2017 06:38:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dzKb5-00032j-Tw for guix-devel@gnu.org; Tue, 03 Oct 2017 06:38:44 -0400 Received: from dustycloud.org ([2600:3c02::f03c:91ff:feae:cb51]:44566) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1dzKb5-00030y-Jq for guix-devel@gnu.org; Tue, 03 Oct 2017 06:38:43 -0400 In-reply-to: <87h8vgegdr.fsf@netris.org> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Mark H Weaver Cc: guix-devel@gnu.org Mark H Weaver writes: > Tobias Platen writes: > >> On 02.10.2017 20:52, Christopher Allan Webber wrote: >>> Since these don't provide Guix in the main repo (and Debian won't >>> because we violate the FHS with /gnu/) we could probably auto-generate >>> the .deb or .rpm from some gexp? >>> >> Debian also includes GNUstep which lives in /usr/gnustep. Maybe /gnu >> could be moves to /usr/gnu on Debian. > > All of our binary substitutes are built with a store prefix of /gnu. > Using a different store prefix requires bootstrapping the entire system > from source code, once per core-updates cycle, and also doing frequent > rebuilds of upper layers of the stack to keep up with the updates on our > master branch. Most users won't want to do this. I still think a hilarious option would be to "graft" every output to /usr/gnu or /opt/gnu but I think nobody else is on board with this ;)