| 1 |
On Thu, Aug 1, 2013 at 5:42 PM, Andreas K. Huettel <dilfridge@g.o> wrote: |
| 2 |
> Am Donnerstag, 1. August 2013, 23:16:26 schrieb Rich Freeman: |
| 3 |
>> |
| 4 |
>> I do favor the dropping of support for separate /usr without an early |
| 5 |
>> boot workaround. I just don't think the council should actually step |
| 6 |
>> in until somebody needs us to, or as part of some larger plan. If the |
| 7 |
>> base-system maintainers have things under control, better to let them |
| 8 |
>> handle it. |
| 9 |
>> |
| 10 |
> |
| 11 |
> 1) I have some doubts that this is really "under control". Maybe someone from |
| 12 |
> base-system should comment how well booting with separate usr AND without |
| 13 |
> early boot mechanism works. (That's also where Diego's blog posts come in.) |
| 14 |
|
| 15 |
To clarify - I mean that things are under control in the sense that |
| 16 |
nobody on base-system besides williamh seems to really care about |
| 17 |
having the decision clarified. I agree completely with Diego's |
| 18 |
assessment/etc. Today a system with a separate /usr and no |
| 19 |
initramfs/etc generally works, but sometimes does not. |
| 20 |
|
| 21 |
> |
| 22 |
> 2) The main difficulty is that last council decided "something" and everyone |
| 23 |
> has a different opinion on what was actually decided. |
| 24 |
|
| 25 |
The thing is that I've yet to see any actual difficulty come up. If |
| 26 |
the udev team moved everything to /usr and there was an uproar and QA |
| 27 |
told them that they consider it a violation, then I'd cal that an |
| 28 |
actual difficulty (in which case I'd tell the udev team that they |
| 29 |
don't have to worry about it as long as they don't break |
| 30 |
genkernel/dracut/busybox/whatever). |
| 31 |
|
| 32 |
> |
| 33 |
> 3) If things are not "under control", no council decision will magically fix |
| 34 |
> that. |
| 35 |
|
| 36 |
I mainly advocate laissez faire on this issue, so from my standpoint |
| 37 |
there really is nothing to fix unless some maintainer is being given a |
| 38 |
hard time. That is something the council definitely can fix, because |
| 39 |
devrel isn't going to counter a council decision, and even if they did |
| 40 |
they can be appealed - the rest is just hot air. |
| 41 |
|
| 42 |
> |
| 43 |
> 4) We should also remind ourselves that the general Gentoo philosophy used to |
| 44 |
> be "follow upstream as much as possible". Given the general direction in Linux |
| 45 |
> outside Gentoo, more and more software may migrate into /usr. Do we want to |
| 46 |
> step up patching? |
| 47 |
|
| 48 |
Yup. If we're going to patch it seems like a better move to just |
| 49 |
patch things the other way and do the /usr move so that there is at |
| 50 |
least some kind of larger benefit from the change. That's why I think |
| 51 |
the whole "is separate /usr without an early boot mechanism a |
| 52 |
supported configuration" bit is a bit of a sideshow. I'm happy to |
| 53 |
settle it if somebody wants us to, but if nobody cares then we're |
| 54 |
basically making policy for the sake of having policy. I'd rather see |
| 55 |
us look beyond this and decide where we want to be. To me the only |
| 56 |
logical choices are FHS or /usr move, and to strictly follow the |
| 57 |
former is slowly turning into just sticking everything in / - |
| 58 |
something that shouldn't make sense to anybody. |
| 59 |
|
| 60 |
Bottom line is that I'm happy to render a clear decision if anybody |
| 61 |
really will benefit from having one, but I think the bigger picture is |
| 62 |
that we should focus less on what we don't support and focus more on |
| 63 |
what we do support. |
| 64 |
|
| 65 |
Rich |
Archives