unofficial mirror of meta@public-inbox.org
 help / color / mirror / Atom feed
From: Eric Wong <e@80x24.org>
To: "Σταύρος Ντέντος" <stdedos@gmail.com>
Cc: meta@public-inbox.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>

Σταύρος Ντέντος <stdedos@gmail.com> wrote:
> On Sat, 27 Mar 2021 at 11:54, Eric Wong <e@80x24.org> 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

  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 [PATCH v1] git-send-email-reply: Append subject 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 \
    --to=e@80x24.org \
    --cc=meta@public-inbox.org \
    --cc=stdedos@gmail.com \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).