From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Clemmer Subject: bug#31786: 'pre-inst-env guix --version' is not updated by new commits" Date: Fri, 15 Jun 2018 15:13:15 -0400 Message-ID: <8736xnj22c.fsf@gmail.com> References: <87r2lddwyg.fsf@gmail.com> <87k1r4p2ca.fsf@gnu.org> <87k1r3271g.fsf@gmail.com> <87d0wvoicy.fsf@gnu.org> <87o9gf5x0t.fsf@gmail.com> <87wov3npl2.fsf@gnu.org> <20180614013938.GD29167@jasmine.lan> <87d0wttn0v.fsf@gmail.com> <87k1r1z5o0.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:47023) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fTuAg-0008Jz-38 for bug-guix@gnu.org; Fri, 15 Jun 2018 15:14:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fTuAc-0007kw-1R for bug-guix@gnu.org; Fri, 15 Jun 2018 15:14:06 -0400 Received: from debbugs.gnu.org ([208.118.235.43]:42768) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fTuAb-0007kh-S4 for bug-guix@gnu.org; Fri, 15 Jun 2018 15:14:01 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1fTuAb-0000K5-Kj for bug-guix@gnu.org; Fri, 15 Jun 2018 15:14:01 -0400 Sender: "Debbugs-submit" Resent-Message-ID: In-reply-to: <87k1r1z5o0.fsf@gnu.org> List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: "bug-Guix" To: Ludovic =?UTF-8?Q?Court=C3=A8s?= , =?UTF-8?Q?Cl=C3=A9ment?= Lassieur Cc: 31786@debbugs.gnu.org Ludovic Court=C3=A8s writes: > Hi George, > > George Clemmer skribis: > >> Leo Famulari writes: >> >>> On Wed, Jun 13, 2018 at 08:54:49AM +0200, Ludovic Court=C3=A8s wrote: >>>> The other aspect, from a maintenance and readability viewpoint, is that >>>> we could quickly add up lots of explanations that we=E2=80=99ll have t= o keep >>>> up-to-date and that may make more important information harder to find. >>> >>> Yeah, I'm worried about this too. It's tough to strike the correct >>> balance. >> >> IMO Guix is great for hackers, maintainers and sysops. The doc is >> appropriate for such users, well done, spare, and already voluminous. >> >> This footnote suggestion, and others rejected in the past, are motivated >> by my assumption that you will want to make Guix attractive to less >> sophisticated users. >> >> Maybe my assumption is wrong? Maybe you want only "elite" users? > > No, definitely not; I=E2=80=99m sorry if this is the impression this gave. > > Like I wrote, my main concern is about keeping the documentation focused > and maintainable. Sometimes we have to document things that are > technically outside of Guix because there=E2=80=99s no real canonical > documentation and because users would be impaired without it=E2=80=94I=E2= =80=99m > thinking for instance of bits in the =E2=80=9CPreparing for Installation= =E2=80=9D > section. > > In this case, we=E2=80=99d be documenting something that=E2=80=99s both o= utside of Guix > and not vital for routine usage, and that=E2=80=99s mostly covered by the > Autoconf manual. Hence my reluctance. > > I hope that makes sense. Hi Ludo=E2=80=99, I see the situation this way: The current doc reflects the needs and sensibilities of the hackers, maintainers, and sysops that have built Guix. These "elite" users have different needs and judge what is important quite differently from end users. This guarantees that the current doc is inadequate for end users. So, if, as you say, you want to make Guix accessible to end users, you need to make changes in the doc. The questions: How? What? May I suggest ... a) Adopt a less defensive posture when responding to user questions, comments, and bug reports. b) Be pro-active about capturing support resolutions in the doc. This thread presents a nice example of what I am talking about. To recap: I said: I use 'pre-inst-env guix' this way and this is a bug. You said: Developers expect this, so it's not a bug. A less defensive response: Hmm, You are using 'pre-inst-env guix' in a way we didn't anticipate. What are the benefits of using it this way? I see how this is a bug for your use case. We discussed a workaround. I suggested adding it to the doc. You said: I=E2=80=99m not comfortable documenting this because it=E2=80=99s= nothing specific to Guix. I said: I urge you to reconsider. You said: This part of the manual targets developers... they know where to look things up. [The more we write the more we have to maintain.] And Cl=C3=A9ment Lassieur added: > But non-hacker users can use Guix pull! Running Guix before it is > installed (with pre-inst-env) is described in the manual as a "Hacker > trick". > Guix pull is well documented, and should be usable for non-elite users. OK, but I'm non-elite and I have used Guix for 2+ years. I have tried both. I prefer pre-inst-env. I expect others will too. The fact is that pre-inst-env does not correctly report the version after 'git pull; make'. How can you know that this won't be a problem for other users? It only takes 4 lines to explain this and provide a workaround, e.g., Proposed (revised) footnote: (3) The Guix version in the Guix build is set by './bootstrap'. Thus, the version reported by './pre-inst-env guix --version' is not updated by subsequent 'git pull; make' steps. To update the version (and rebuild everything), use 'git clean -dfx; ./bootstrap; ./configure; make'. - George