| 1 |
On 10/14/2013 03:32 AM, William Hubbs wrote: |
| 2 |
> All, |
| 3 |
> |
| 4 |
> from what I'm seeing, we should look into converting /etc/mtab to a |
| 5 |
> symlink to /proc/self/mounts [1]. |
| 6 |
> |
| 7 |
> Are there any remaining concerns about doing this? |
| 8 |
|
| 9 |
Apart from breaking umount -a and some other things? |
| 10 |
None at all ;) |
| 11 |
|
| 12 |
(The breakage is visible e.g. with umount -a tmpfs, which used to be |
| 13 |
quite useful if you had a few chroots with /var/tmp/portage as tmpfs and |
| 14 |
wanted to reset them. Now it'll also punt random things like /run if |
| 15 |
you're lucky - and in the past it knocked out the OpenRC state directory |
| 16 |
reliably) |
| 17 |
|
| 18 |
There are pretty good historical reasons for having /etc/mtab as a file, |
| 19 |
maybe you should do some archeology before just trying to change things. |
| 20 |
|
| 21 |
Applications that can't handle a properly set up Linux system should be |
| 22 |
patched to either use /proc/mounts unconditionally or randomly segfault |
| 23 |
to emulate proper Windows best practises. |
| 24 |
|
| 25 |
> |
| 26 |
> If not, it seems like it would be pretty easy to make baselayout create |
| 27 |
> this symlink in the stages (I'm willing to do this work), but what about |
| 28 |
> on systems that are already installed? Should we send out a news item |
| 29 |
> and have everyone convert their /etc/mtab manually or find a way to |
| 30 |
> automate that? |
| 31 |
|
| 32 |
... you automate that, you get a few angry bugs. |
| 33 |
Better to warn, if you absolutely have to, and let users consciously |
| 34 |
remove features when they are ready for it. |
| 35 |
|
| 36 |
Thanks, |
| 37 |
|
| 38 |
Patrick |
Archives