On Wed, Jan 10, 2024 at 11:49:02AM -0800, Mike Castle wrote:
To some extent, it will make it easier for packaging.
No, not at all--new packages have not had to worry about putting things
anywhere but /usr for a long time. Only old packages (for which the work
you described had been done
On Wed, Jan 10, 2024 at 11:49:02AM -0800, Mike Castle wrote:
> On Wed, Jan 10, 2024 at 10:57 AM wrote:
> > Yes, the main reason for the separation of /usr has more or less
> > disappeared with the arrival of initramfs, but still... why.
>
> To some extent, it will make it easier for packaging.
> If you were to issue 'ls -l /' You'll find that /bin, /sbin,
> lib{32,64,x32} are linked to their counterparts in /usr/. I under-
> stand the logic in doing so. However, for specific reasons that would
> require exhaustive explanations that I would prefer to save us all from
> me doing, I would
Hello,
On Wed, Jan 10, 2024 at 10:41:05AM -0800, Mike Castle wrote:
> I did that for years.
>
> Then again, when I started doing that, I was using PLIP over a
> null-printer cable. But even after I could afford larger harddrives
> (so I had room to install /usr), and Ethernet cards (and later a
On Wed, Jan 10, 2024 at 10:57 AM wrote:
> Yes, the main reason for the separation of /usr has more or less
> disappeared with the arrival of initramfs, but still... why.
To some extent, it will make it easier for packaging.
Look at any package built using autoconf, for instance, you run:
On Wed, Jan 10, 2024 at 10:41:05AM -0800, Mike Castle wrote:
> On Wed, Jan 10, 2024 at 9:53 AM Andy Smith wrote:
> > น There was another use-case which is "sharing a read-only /usr
> > between systems by NFS, etc." but at the time this was widely
> > regarded a lost cause as so many other
On Wed, Jan 10, 2024 at 9:53 AM Andy Smith wrote:
> น There was another use-case which is "sharing a read-only /usr
> between systems by NFS, etc." but at the time this was widely
> regarded a lost cause as so many other things violated the
> premise.
I did that for years.
Then again,
Hello,
On Wed, Jan 10, 2024 at 05:06:33AM +, miphix wrote:
> If you were to issue 'ls -l /' You'll find that /bin, /sbin,
> lib{32,64,x32} are linked to their counterparts in /usr/. I under-
> stand the logic in doing so. However, for specific reasons that would
> require exhaustive
On Wed, 10 Jan 2024, Jeffrey Walton wrote:
I think some programs can break, like those that assume / and /usr are
both mounted early in the boot process. I think the only guarantee is
/ will be mounted early, and all programs needed to boot are available
from /. I thought there was a
On Wed, Jan 10, 2024 at 12:49 AM wrote:
>
> On Wed, Jan 10, 2024 at 05:06:33AM +, miphix wrote:
> > If you were to issue 'ls -l /' You'll find that /bin, /sbin,
> > lib{32,64,x32} are linked to their counterparts in /usr/. I under-
> > stand the logic in doing so. However, for specific
On Wed, 10 Jan 2024, miphix wrote:
If you were to issue 'ls -l /' You'll find that /bin, /sbin,
lib{32,64,x32} are linked to their counterparts in /usr/. I under-
stand the logic in doing so. However, for specific reasons that would
require exhaustive explanations that I would prefer to save us
Hi, miphix
On Wed, Jan 10, 2024 at 05:06:33AM +, miphix wrote:
> If you were to issue 'ls -l /' You'll find that /bin, /sbin,
> lib{32,64,x32} are linked to their counterparts in /usr/. I under-
> stand the logic in doing so. However, for specific reasons that would
> require exhaustive
If you were to issue 'ls -l /' You'll find that /bin, /sbin,
lib{32,64,x32} are linked to their counterparts in /usr/. I under-
stand the logic in doing so. However, for specific reasons that would
require exhaustive explanations that I would prefer to save us all from
me doing, I would like to
13 matches
Mail list logo
