| 1 |
On Thursday 27 December 2012 13:49:50 Rich Freeman wrote: |
| 2 |
> I think moving everything into /usr is a good idea. However: |
| 3 |
|
| 4 |
i don't think it's hard to support both. the majority of packages just want |
| 5 |
to relocate shared libs into / from /usr and that's easy with one line: |
| 6 |
gen_usr_ldscript -a foo |
| 7 |
put a knob into the func itself (perhaps a var set in the profile's |
| 8 |
make.defaults) and you've addressed more than 50% of the problem. |
| 9 |
|
| 10 |
very few packages actually install into /bin and /sbin, and i don't mind a |
| 11 |
USE=sep-usr flag for them (relevant since i also see that i'm maintaining most |
| 12 |
of those packages). |
| 13 |
|
| 14 |
> 3. Moving just a bunch of libraries to /usr and nothing else is dumb. |
| 15 |
> It brings none of the benefits of the /usr move |
| 16 |
|
| 17 |
sure |
| 18 |
|
| 19 |
> and gets rid of all |
| 20 |
> of the benefits of complying with FHS (like systems booting fine with |
| 21 |
> a separate /usr - and yes I know this is already "broken" despite the |
| 22 |
> fact that it works just fine for 99% of the people running in this |
| 23 |
> configuration). |
| 24 |
|
| 25 |
strictly speaking, i don't think FHS mandates sep /usr be supported. it's |
| 26 |
fairly easy to read a merged /usr setup as being FHS compliant. |
| 27 |
|
| 28 |
> But, until the Council decides that we're really doing a coordinated |
| 29 |
> /usr move, then let's leave things alone. Sticking stuff in random |
| 30 |
> locations per the whim of individual maintainers will cause nothing |
| 31 |
> but trouble. |
| 32 |
|
| 33 |
aka today's status quo |
| 34 |
-mike |
Archives