My personal opinion:
Unless we have a good reason to do otherwise, don't fuck with upstream.
On Thu, Apr 7, 2016 at 8:12 PM, Damien Levac wrote:
>
> > Three points :-
> > 1) systemd - not all gentoo users subscribe to this 'philosophy' .. >but
> >no, I don't want get drawn into debates of yes/n
> Three points :-
> 1) systemd - not all gentoo users subscribe to this 'philosophy' .. >but
>no, I don't want get drawn into debates of yes/no of systemd ..
The article start by saying the points are not just for systemd, even
though the latter might find the merge more 'needed'...
>2) "Today,
On 08/04/16 03:36, Damien Levac wrote:
> Anybody who have this kind of misconception about 'usr merge' should
> read this:
>
> https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/
>
> Signed,
>
> a user who got scared by this thread and documented myself before
> freaking out to
Anybody who have this kind of misconception about 'usr merge' should
read this:
https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/
Signed,
a user who got scared by this thread and documented myself before
freaking out too much...
>> Personally I think that merging things i
On 08/04/16 02:42, William Hubbs wrote:
> On Thu, Apr 07, 2016 at 08:39:07PM -0500, William Hubbs wrote:
>> On Thu, Apr 07, 2016 at 01:18:01PM -0700, Raymond Jennings wrote:
>>> Personally I think that merging things into /usr is a major policy decision
>>> that is likely to contravene upstream ins
On Thu, Apr 07, 2016 at 08:39:07PM -0500, William Hubbs wrote:
> On Thu, Apr 07, 2016 at 01:18:01PM -0700, Raymond Jennings wrote:
> > Personally I think that merging things into /usr is a major policy decision
> > that is likely to contravene upstream installation locations. I wouldn't
> > do it
On Thu, Apr 07, 2016 at 01:18:01PM -0700, Raymond Jennings wrote:
> Personally I think that merging things into /usr is a major policy decision
> that is likely to contravene upstream installation locations. I wouldn't
> do it lightly, if at all.
Actually, there are upstreams that already do this
Personally I think that merging things into /usr is a major policy decision
that is likely to contravene upstream installation locations. I wouldn't
do it lightly, if at all.
On Thu, Apr 7, 2016 at 11:54 AM, Rich Freeman wrote:
> On Thu, Apr 7, 2016 at 2:32 PM, M. J. Everitt wrote:
> > In the
On Thu, Apr 7, 2016 at 2:32 PM, M. J. Everitt wrote:
> In the spirit of hearing arguments for/against .. could someone with the
> appropriate 'fu' throw up a quick survey for those on this ML (and/or
> possibly the g-users?) to indicate a preference for a change to a
> flattened-/usr system?
>
> I
On 07/04/16 17:36, Alexis Ballier wrote:
> On Thursday, April 7, 2016 6:22:16 PM CEST, Rich Freeman wrote:
>> Again, I don't see this as a reason not to make it optional, but I
>> suspect that we will find bugs here from time to time which users who
>> run with the split /usr will have to report/fi
May I suggest first moving everything into /usr one at a time, and for each
file moved out of /bin or /sbin or whatever, replace it with a symlink?
This will allow the /bin and /sbin directories themselves to atomically be
replaced with symlinks later.
Doing it all at once will leave a gap.
For
On Thursday, April 7, 2016 6:22:16 PM CEST, Rich Freeman wrote:
Again, I don't see this as a reason not to make it optional, but I
suspect that we will find bugs here from time to time which users who
run with the split /usr will have to report/fix.
Considering the advantages of usr-merge are
On Thu, Apr 7, 2016 at 11:46 AM, William Hubbs wrote:
>> #!/bin/bash will work whether you've done a usr merge or not
>> #!/usr/bin/bash will probably only work if you've done the usr merge
>> #!/usr/bin/python will work whether you've done a usr merge or not
>> #!/bin/python will probably only wo
On Thu, Apr 07, 2016 at 11:42:01AM -0400, Rich Freeman wrote:
> On Thu, Apr 7, 2016 at 11:12 AM, Duncan <1i5t5.dun...@cox.net> wrote:
> > William Hubbs posted on Thu, 07 Apr 2016 09:40:49 -0500 as excerpted:
> >
> >> After the testing period is over, I'm confused about why we should
> >> support bo
On Thu, Apr 7, 2016 at 11:12 AM, Duncan <1i5t5.dun...@cox.net> wrote:
> William Hubbs posted on Thu, 07 Apr 2016 09:40:49 -0500 as excerpted:
>
>> After the testing period is over, I'm confused about why we should
>> support both layouts. With separate usr without initramfs gone, the usr
>> merge i
William Hubbs posted on Thu, 07 Apr 2016 09:40:49 -0500 as excerpted:
> After the testing period is over, I'm confused about why we should
> support both layouts. With separate usr without initramfs gone, the usr
> merge is transparent to end users because of the symbolic links in /, so
> there sh
# Michael Palimaka (07 Apr 2016)
# Obsolete. Merged into media-libs/libexif.
# Masked for removal in 30 days.
media-libs/libmnote
On Thu, Apr 07, 2016 at 11:12:13AM +0200, Alexis Ballier wrote:
> On Wednesday, April 6, 2016 11:36:09 PM CEST, Richard Yao wrote:
> > As for those benefits, they do little for {/usr,}/sbin vs
> > {/usr,}/bin, which is where the incompatibilities tend to live.
> > I encountered one of these in po
On Wed, Apr 6, 2016 at 4:04 PM, Richard Yao wrote:
> On Apr 6, 2016, at 3:42 AM, Alexis Ballier wrote:
>> On Wednesday, April 6, 2016 6:15:58 AM CEST, Richard Yao wrote:
>>>
>>> Here are the violations:
>>>
>>> http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#binEssentialUserCommandBinari
On Wednesday, April 6, 2016 11:36:09 PM CEST, Richard Yao wrote:
As for those benefits, they do little for {/usr,}/sbin vs
{/usr,}/bin, which is where the incompatibilities tend to live.
I encountered one of these in powertop the other day (patch
pending). The benefits of being able to access t
On Wednesday, April 6, 2016 5:52:52 PM CEST, Richard Yao wrote:
The original purpose of the /usr merge in Solaris was to make managing
updates easier. Redhat realized that and copied it. Copying it too
without doing the enabling work necessary for a rolling distribution
would be setting a trap fo
21 matches
Mail list logo
