BLU Discuss list archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Discuss] Debian 12 vs. WSL 1
- Subject: [Discuss] Debian 12 vs. WSL 1
- From: grg-webvisible+blu at ai.mit.edu (grg)
- Date: Wed, 21 Jun 2023 22:13:14 -0400
- In-reply-to: <20230621160423.GI24375@bladeshadow.org>
- References: <20230617001817.GE24375@bladeshadow.org> <20230617000719.GC24375@bladeshadow.org> <ZI3joxAhn/hBUEjJ@csail.mit.edu> <20230620190819.GG24375@bladeshadow.org> <ZJJS7tyoCe0SgsHs@csail.mit.edu> <20230621160423.GI24375@bladeshadow.org>
On Wed, Jun 21, 2023 at 11:04:23AM -0500, Derek Martin wrote: > Not really, no. In 1994--at the time that I spoke of-- ... > So again, NO, when my environment caused me no headaches in regard to > the issues Rich described, it's absolutely not because any developer > or package maintainer was looking out for me. Cuz that DID NOT > HAPPEN. It's entirely because my team did a good job setting up the > environment and planning ahead to address these types of issues. That > may or may not have included creating symlinks. by the late 80s, distributed software commonly had a 'configure' script which (among other things) located the paths of executables and libraries the software distribution needed. the first step of installing such a software package on your system was running './configure'. if in the 90s you ever read usenet news via rn or trn or rrn, have a look behind the curtain (and note the $Id: 1997, fairly close to your stated epoch): https://github.com/acli/trn/blob/master/Configure e.g. line 1200 starts a couple hundred lines of finding the right paths. line 500 also begins a similar block. notice how hard the script is working so that when the software package is installed it knows exactly where to find what it needs: paths='/bin /usr/bin /usr/local/bin /usr/ucb /usr/local /usr/lbin' paths="$paths /opt/bin /opt/local/bin /opt/local /opt/lbin" paths="$paths /usr/5bin /etc /usr/gnu/bin /usr/new /usr/new/bin /usr/nbin" paths="$paths /opt/gnu/bin /opt/new /opt/new/bin /opt/nbin" paths="$paths /sys5.3/bin /sys5.3/usr/bin /bsd4.3/bin /bsd4.3/usr/ucb" paths="$paths /bsd4.3/usr/bin /usr/bsd /bsd43/bin /usr/ccs/bin" paths="$paths /etc /usr/lib /usr/ucblib /lib /usr/ccs/lib" paths="$paths /sbin /usr/sbin /usr/libexec" I think we can agree that this config script was indeed written and extended by developers and ported and patched by maintainers. so when rn or trn or rrn worked on your system for you or other users, it was in fact because of the effort of developers and maintainers, even if that effort may not have been obviously visible. I don't doubt that you added symlinks on the systems you ran to make some things work better, so even if those weren't obviously visible I'm sure you deserve your credit for that effort. I just don't get why you're so all-caps adamant about denying others credit for their effort. > But you seem convinced that this is only about package management, you might be misinterpreting my statements on usrmerge? what I've said a few times is that I believe usrmerge was pushed by package/distro maintainers to solve *their* problems. more specifically, their problems are primarily porting, and sometimes developing, cross-platform software; my first email on this detailed in its first paragraph that in particular, porting software or applying a patch that references a bin/sbin/lib path may require a fix pre-usrmerge, but post-usrmerge will require less or no path-futzing effort. in short, I've always been convinced the usrmerge push is about reducing their ongoing porting and development effort. note that "porting software" and "developing cross-platform software" are a core focus of "compatibility with other unixes" -- so perhaps we're reaching the same conclusion, even if I wouldn't characterize what I'm saying as "only about package management?" (but perhaps the above is indeed what you mean when you say "only about package management?" if so, then we're in full agreement.) --grg
- Follow-Ups:
- [Discuss] Debian 12 vs. WSL 1
- From: invalid at pizzashack.org (Derek Martin)
- [Discuss] Debian 12 vs. WSL 1
- References:
- [Discuss] Debian 12 vs. WSL 1
- From: invalid at pizzashack.org (Derek Martin)
- [Discuss] Debian 12 vs. WSL 1
- From: invalid at pizzashack.org (Derek Martin)
- [Discuss] Debian 12 vs. WSL 1
- From: grg-webvisible+blu at ai.mit.edu (grg)
- [Discuss] Debian 12 vs. WSL 1
- From: invalid at pizzashack.org (Derek Martin)
- [Discuss] Debian 12 vs. WSL 1
- From: grg-webvisible+blu at ai.mit.edu (grg)
- [Discuss] Debian 12 vs. WSL 1
- From: invalid at pizzashack.org (Derek Martin)
- [Discuss] Debian 12 vs. WSL 1
- Prev by Date: [Discuss] Program path maintenance and security (was Re: Debian 12 vs. WSL 1)
- Next by Date: [Discuss] Program path maintenance and security (was Re: Debian 12 vs. WSL 1)
- Previous by thread: [Discuss] Debian 12 vs. WSL 1
- Next by thread: [Discuss] Debian 12 vs. WSL 1
- Index(es):