On 01/03/2016 04:23 AM, Martinx - ジェームズ wrote:
> This "UseMerge" just brings more insanity into Debian. What is wrong
> with you guys?! For God's sake...
Even if you disagree with something, please don't call it insanity.
> It violates the FHS 2.3 standards.
Sure, if you mean the sentence that "/" needs to have the tools to
mount the other filesystems. I can even one-up you: the same sentence
is present in FHS 3.0, so it also violates that. So what?
- Debian already violates FHS when it comes to {,/usr}/lib: the
Multi-Arch specification of Debian, which adds things like
/usr/lib/x86_64-linux-gnu doesn't conform to FHS. But there is a
very good technical reason why to use /usr/lib/<triplet> instead
of /usr/lib{32,64}. (which are in FHS!)
The question is always: is there a good technical reason for the
violation? Or is it just arbitrary. In case of the UsrMerge there
are good technical reasons for doing so (and I'm sorry, even if you
disagree with the assessment that they outweigh the disatvantages,
you should acknowledge that there _are_ advantages).
So: a game storing its data in /highscores is a FHS violation where
it makes sense to say "please don't do that", because there is NO
advantage over "/var/lib/$game/highscores" or similar. But UsrMerge
doesn't fall into that category.
(Btw. if you consider what I've said in [1], you could argue that
Debian already doesn't properly follow the FHS in all cases,
because /usr on NFS in Jessie *only* works if mounted in initrd at
the moment.)
- Don't forget why the FHS was created: to unify Linux distributions.
Most major Linux distributions (except Debian and Ubuntu) have
switched to a shared /usr, for quite a while actually.
So it could actually be the case that the next version of the FHS
standard will say that /lib etc. should be symlinks to /usr/lib and
that everything should be in /usr. If that were to be the case in
FHS 4.0 or so - would you then say "oh, now Debian must switch and
follow that"?
Sorry, but bringing the FHS into this is just not a good argument.
[1] https://lists.debian.org/debian-devel/2016/01/msg00089.html
> Also, if you guys (Debian) reeeeeeeally wants to move everything to
> /usr, so, there is no reason for any symbolic links at the root file
> system.
In the (very) long run - maybe. But in the short term, they have to be
there. Just two very trivial examples (there are *many* more):
- /bin/sh is hard-coded in SO many places (and required by I don't
know how many different standards to be present)
- The kernel tries to execute /sbin/init by default if init= is not
specified.
You can't just get rid of those.
> Again, If Debian wants to do that, then, do NOT create any symlink on
> the root file system. Do not bring CentOS shit to our shiny
> distribution.
>
> Those symlinks:
>
> "/bin -> /usr/bin"
> "/sbin -> /usr/sbin"
> "/lib -> /usr/lib"
> "/lib64 -> /usr/lib64"
>
> Looks very, very unprofessional.
"Looks unprofessional"? Do you really want a response here?
Btw. symlinks in / are nothing new: on a default installation the
kernel packages symlink the most recent initrd.img and vmlinuz to /.
I've seen a lot of systems where network filesystems mounted via
autofs were symlinked to /, i.e. /var/autofs is a directory handled
by the autofs daemon and there are symlinks such as
/shared => /var/autofs/shared
/backup => /var/autofs/backup
in the root filesystem so people can easily access those things.
> It looks like a huge workaround,
> created to deal with something that you broke for no reason.
On Jessie:
$ find /usr/bin -type l | xargs readlink | grep -E '^/s?bin'
/sbin/on_ac_power
/bin/lesskey
/bin/nano
/bin/less
/bin/dumpkeys
/bin/lesspipe
/sbin/xtables-multi
/bin/chacl
/bin/lesspipe
/bin/lessecho
/bin/which
/bin/getfacl
/bin/setfacl
/bin/loadkeys
/bin/touch
15 compatibility symlinks on my system in /usr/bin because they were
moved to / from /usr.
After /usr-merge there would be 4 links in / for /lib, /lib64, /bin
and /sbin to their counterparts in /usr.
=> 15 - 4 = 11 fewer compatibility symlinks if /usr is merged.
So UsrMerge actually reduces the number of compatibility
"workarounds" as you call them.
Regards,
Christian
Attachment:
signature.asc
Description: OpenPGP digital signature