| 1 |
On Thu, Apr 7, 2016 at 11:12 AM, Duncan <1i5t5.duncan@×××.net> wrote: |
| 2 |
> William Hubbs posted on Thu, 07 Apr 2016 09:40:49 -0500 as excerpted: |
| 3 |
> |
| 4 |
>> After the testing period is over, I'm confused about why we should |
| 5 |
>> support both layouts. With separate usr without initramfs gone, the usr |
| 6 |
>> merge is transparent to end users because of the symbolic links in /, so |
| 7 |
>> there should be no reason to keep supporting both layouts once we are |
| 8 |
>> satisfied with the migration process. |
| 9 |
> |
| 10 |
> Because we're Gentoo, and gentooers tend to have rather strong opinions |
| 11 |
> on what sort of choices we should be able to make about things like that. |
| 12 |
> |
| 13 |
|
| 14 |
I'm trying to think of whether offering a choice really costs us |
| 15 |
anything. The main issue I see here is that the compatibility |
| 16 |
symlinks only go one way. |
| 17 |
|
| 18 |
#!/bin/bash will work whether you've done a usr merge or not |
| 19 |
#!/usr/bin/bash will probably only work if you've done the usr merge |
| 20 |
#!/usr/bin/python will work whether you've done a usr merge or not |
| 21 |
#!/bin/python will probably only work if you've done the usr merge |
| 22 |
|
| 23 |
It seems like a bit of a challenge to try to make sure that all your |
| 24 |
links are to wherever the original package tries to install files when |
| 25 |
on the system you are developing/testing on everything is in one |
| 26 |
place. |
| 27 |
|
| 28 |
We could of course require that maintainers accept patches to fix |
| 29 |
these kinds of broken links if they're offered, but users would be |
| 30 |
more likely to run into temporary breakage if they didn't use the |
| 31 |
merge unless we can come up with a way to offer compatibility in both |
| 32 |
directions. |
| 33 |
|
| 34 |
Unless there is a bigger problem lurking it probably still should be |
| 35 |
up to the user. |
| 36 |
|
| 37 |
-- |
| 38 |
Rich |
Archives