From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-Status: No, score=-3.2 required=3.0 tests=ALL_TRUSTED,AWL,BAYES_00, BODY_8BITS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from localhost (dcvr.yhbt.net [127.0.0.1]) by dcvr.yhbt.net (Postfix) with ESMTP id 3FF6D1F9FC; Sat, 27 Mar 2021 19:32:32 +0000 (UTC) Date: Sat, 27 Mar 2021 19:32:32 +0000 From: Eric Wong To: =?utf-8?B?zqPPhM6xz43Pgc6/z4Igzp3PhM6tzr3PhM6/z4I=?= Cc: meta@public-inbox.org Subject: Re: [PATCH v1] git-send-email-reply: Append subject Message-ID: <20210327193232.GA11329@dcvr> References: <20210326213517.GA5730@dcvr> <20210327083946.30726-1-133706+stdedos@users.noreply.github.com> <20210327095431.GA32057@dcvr> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: List-Id: Σταύρος Ντέντος wrote: > On Sat, 27 Mar 2021 at 11:54, Eric Wong wrote: > > Not really, since the address is meta@public-inbox.org. > > "public-inbox" is already a long name, and > > "public-inbox.org/public-inbox" is kinda annoyingly long. > > > > (and I've been preferring <80x24.org|yhbt.net>/public-inbox.git > > for the git repo). > > Remember that a symlink (or a 30x redirect) does not cost you anything :-p > It _is_ longer, and it doesn't cost you anything, for the sake of > "finding where is something where you look for it to be" ;-) It does, it clutters up the directory listing ("homepage"). Also redirect adds latency + traffic. If somebody is already looking at public-inbox.org, then "meta/" is already the top link in the listing. > > Everything I've read about Docker sounds scary when people are > > grabbing binaries and code from random distributors and just > > running it blindly. IMHO it encourages dangerous behavior. > > Pulling solely from "sane-ish sources" (buster from Debian and your > code from your repo), > should it be okay. The risks (as stated above) should ... Yes, if public-inbox.org provides a Docker image, it would not be a "sane-ish source" :) > > I would never introduce any soft or hard dependency into a > > project without being knowledgeable and comfortable about it, > > first; and that can take a LOT of time and lead me down rabbit > > holes... > > Yeah, me too :-D > Having a more clean deploy&isolation&remove process would facilitate > in me testing more > and providing a cleaner patchset to you. Fwiw, the test suite runs w/o install. > You might have fixed my patchset yourself (thanks!) but not everyone > is willing to spend time on it. > On the other hand, I am not willing to "pollute" my system with > something tying itself more or less to my system. > (It's not the pollution that I am afraid of, but the sanitization afterwards). Agree. Note public-inbox.git has a new "symlink-install" target that allows a minimimum install footprint: # https://public-inbox.org/meta/20201218120950.23272-24-e@80x24.org/ make symlink-install prefix=/tmp/home export PATH=/tmp/home/bin:$PATH Everything else is available from distro packages and easy to uninstall. > I've barely used chroots, and I am not comfortable using them (because > they require sudo). Understood, I also don't want to advocate use of chroot for testing public-inbox. I've used chroot since it's been available far longer than containers or VMs, so I already learned it ages ago. I still use QEMU VMs to test old kernels and *BSD, and do so with userspace networking (so no root needed). > If you have some tl;dr knowledge on how to make (s)chroots to work > cleanly without any sudo > (after I review a specific subset of rights & get myself access to > e.g. `/var/chroots/*` directory), > I am all ears! I don't, but I would probably look at containers directly or something lighter than docker. It seems systemd-nspawn can work with debootstrap, maybe that is worth exploring, or some other lxc thing. Honestly, it still seems like overkill (I don't want duplicate libc, perl, libz, git, etc. on the disk if I can help it). For testing other stuff, I configure with alternate prefix: ./Configure -Dprefix=... # for perl5.git ./configure --prefix=... # for autotooled stuff make prefix=... # for git.git No root needed at all :> But I rarely build software anymore since it takes too long. > A lot of compiled deb packages use that one way or another, and (mistakenly?) > I feel more comfortable installing via `apt-get install package.deb` > than `make install`. Btw, it's in Debian sid, now: https://packages.debian.org/public-inbox