From: Eric Wong <firstname.lastname@example.org> To: "Σταύρος Ντέντος" <email@example.com> Cc: firstname.lastname@example.org Subject: Re: [PATCH v1] git-send-email-reply: Append subject Date: Sat, 27 Mar 2021 19:32:32 +0000 [thread overview] Message-ID: <20210327193232.GA11329@dcvr> (raw) In-Reply-To: <CAHMHMxUEZiWoqGmz4i6aSceGzf=7CZ7u7JJu89=XUFva+9-3Rg@mail.gmail.com> Σταύρος Ντέντος <email@example.com> wrote: > On Sat, 27 Mar 2021 at 11:54, Eric Wong <firstname.lastname@example.org> wrote: > > Not really, since the address is email@example.com. > > "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://firstname.lastname@example.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
next prev parent reply other threads:[~2021-03-27 19:32 UTC|newest] Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-03-26 16:31 Stavros Ntentos 2021-03-26 19:36 ` Eric Wong [not found] ` <CAHMHMxVS4tVvUYvWUmk8L8oqPPxtYW-MF_57Vwuzug-asWQiQg@mail.gmail.com> 2021-03-26 21:35 ` Eric Wong 2021-03-27 8:39 ` Stavros Ntentos 2021-03-27 9:54 ` Eric Wong 2021-03-27 14:01 ` Σταύρος Ντέντος 2021-03-27 19:32 ` Eric Wong [this message] 2021-03-28 16:00 ` Σταύρος Ντέντος 2021-03-28 22:58 ` Eric Wong
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style List information: https://public-inbox.org/README * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20210327193232.GA11329@dcvr \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: [PATCH v1] git-send-email-reply: Append subject' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Code repositories for project(s) associated with this inbox: https://80x24.org/public-inbox.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).