On 06/04/16 17:06, Richard Yao wrote:
>
> That does not address the problems of supporting this configuration in a
> rolling release.
>
> Formats in /etc can fall out of sync with software in /usr. If boot
> options change, the stuff in /etc/init.d is not updated. If you add
> software, the update
On 04/06/2016 11:11 AM, Alexis Ballier wrote:
> On Wednesday, April 6, 2016 4:58:05 PM CEST, M. J. Everitt wrote:
>> What, if any, is the benefit of squashing /usr out of the equation? I
>> happen to have a few workstations that load their /usr off an NFS share
>> presently,
>
>
> This is
On 04/06/2016 10:58 AM, M. J. Everitt wrote:
> What, if any, is the benefit of squashing /usr out of the equation? I
> happen to have a few workstations that load their /usr off an NFS share
> presently, with some bodgery-workarounds I did pre the udev notification
> about initramfs's which I have
On Wednesday, April 6, 2016 4:58:05 PM CEST, M. J. Everitt wrote:
What, if any, is the benefit of squashing /usr out of the equation? I
happen to have a few workstations that load their /usr off an NFS share
presently,
This is precisely one case where I see benefits: no need to correlate /
What, if any, is the benefit of squashing /usr out of the equation? I
happen to have a few workstations that load their /usr off an NFS share
presently, with some bodgery-workarounds I did pre the udev notification
about initramfs's which I have never got around to implementing
(although I'm
On Wednesday, April 6, 2016 4:04:05 PM CEST, Richard Yao wrote:
Most systems would switch fine. The ones configured to depend
on /usr not being mounted in early boot would not. That is the
reason automatically migrating people is not the best idea.
I believe any script/binary should not run
> On Apr 6, 2016, at 4:55 AM, James Le Cuirot wrote:
>
> On Wed, 06 Apr 2016 09:42:04 +0200
> Alexis Ballier wrote:
>
>>> This was invented in Solaris and copied by RHEL. The upgrade
>>> path for the /usr merge on those systems is a complete
>>>
On Wed, 06 Apr 2016 09:42:04 +0200
Alexis Ballier wrote:
> > This was invented in Solaris and copied by RHEL. The upgrade
> > path for the /usr merge on those systems is a complete
> > reinstall. Upgrading from RHEL6 to RHEL7 this Solaris 10 to
> > Solaris 11 is not
On Wednesday, April 6, 2016 6:15:58 AM CEST, Richard Yao wrote:
On Apr 4, 2016, at 9:19 PM, William Hubbs wrote:
All,
I thought that since the usr merge is coming up again, and since I lost
track of the message where it was brought up, I would open a
new thread to discuss
> On Apr 4, 2016, at 9:19 PM, William Hubbs wrote:
>
> All,
>
> I thought that since the usr merge is coming up again, and since I lost
> track of the message where it was brought up, I would open a
> new thread to discuss it.
>
> When it came up before, some were saying
On Tuesday, April 5, 2016 2:26:53 PM CEST, Duncan wrote:
Alexis Ballier posted on Tue, 05 Apr 2016 12:10:51 +0200 as excerpted:
On Tuesday, April 5, 2016 3:19:59 AM CEST, William Hubbs wrote:
[...] ...
As I said in the other thread, I'm running merged /usr and bin/sbin here,
except that I
On Tuesday, April 5, 2016 3:19:59 AM CEST, William Hubbs wrote:
[...]
I don't think creating usr merged stages would be that difficult. I
think it would just be a matter of creating a new version of baselayout
that puts these symlinks in place:
/bin->usr/bin
/lib->usr/lib
/lib32->usr/lib32
All,
I thought that since the usr merge is coming up again, and since I lost
track of the message where it was brought up, I would open a
new thread to discuss it.
When it came up before, some were saying that the /usr merge violates
the fhs. I don't remember the specifics of what the claim was
Alexis Ballier posted on Mon, 04 Apr 2016 09:12:16 +0200 as excerpted:
>> The /usr merge is a separate issue, which I agree with as well, but
>> that was never brought to council, and it is controversial in the
>> Gentoo camp because some folks claim fhs doesn't allow it.
>
> Getting a bit OT,
101 - 114 of 114 matches
Mail list logo