Σταύρος Ντέντος <[email protected]> wrote:
> On Sat, 27 Mar 2021 at 11:54, Eric Wong <[email protected]> wrote:
> > Not really, since the address is [email protected].
> > "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/[email protected]/
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
--
unsubscribe: one-click, see List-Unsubscribe header
archive: https://public-inbox.org/meta/
