Ceph

see also #2975

https://github.com/ceph/ceph/pull/4412

Kefu Chai wrote:

Ken, i am not sure we should document the ceph-disk-{udev,activate,prepare}. they are called by our udev rules. so, IMHO, they are just internals of ceph, instead of the interface to our user. what do you think?

Would it make sense to move them out of the user's $PATH, in that case, so users do not try to run them?

For example, ceph-osd-prestart.sh is in /usr/libexec/ceph. Should we put these utilities there as well?

Ken Dreyer wrote:

Kefu Chai wrote:

Ken, i am not sure we should document the ceph-disk-{udev,activate,prepare}. they are called by our udev rules. so, IMHO, they are just internals of ceph, instead of the interface to our user. what do you think?

Would it make sense to move them out of the user's $PATH, in that case, so users do not try to run them?

For example, ceph-osd-prestart.sh is in /usr/libexec/ceph. Should we put these utilities there as well?

maybe we should put them into /usr/share/ceph ? since they are architecture independent files. see http://refspecs.linuxfoundation.org/FHS_2.3/fhs-2.3.html#USRSHAREARCHITECTUREINDEPENDENTDATA .

and /usr/libexec is for architecture dependent binaries, see https://www.linuxbase.org/betaspecs/fhs/fhs.html#usrlibexec

The FHS reference says /usr/share is for "data files", which I took to mean pictures, etc. However I see that some programs do put scripts into /usr/share (for example, the "createrepo" program does this.)

I've asked for clarification on fedora-devel. https://lists.fedoraproject.org/pipermail/devel/2015-April/210080.html

Ken, i think the crux is architecture dependent versus architecture independent. the stuff in /usr/share is something that can be shared among different architectures, e,g, x86 and amd64. so from the maintainer's POV, if a upstream package supports multi-arch, he/she might want to consider separating the package into smaller pieces. one of the criteria might be architecture dependent or independent.

and the files (including scripts) from the data package should go to /usr/share. and the binary will go to their own places, see https://wiki.debian.org/Multiarch/LibraryPathOverview . sorry, Ken. i am more familiar with deb packaging than rpm packaging. so i am using the examples from the debian/ubuntu world. but i guess the idea also applies to rpm packaging.

let's look at some real-world examples,

• https://packages.debian.org/sid/all/debootstrap/filelist : (debootstrap is a tool to create a Debian base system, so one is able to chroot into it. we can tell that it put shell scripts into /usr/share)
  

  $ head /usr/share/debootstrap/scripts/sid
  mirror_style release
  download_style apt
  finddebs_style from-indices
  variants - buildd fakechroot minbase scratchbox
  keyring /usr/share/keyrings/debian-archive-keyring.gpg
  
  if doing_variant fakechroot; then
          test "$FAKECHROOT" = "true" || error 1 FAKECHROOTREQ "This variant requires fakechroot environment to be started" 
  fi
  

• https://packages.debian.org/sid/all/quilt/filelist? quilt is a tool to manage a set of patches.
  

  $ file /usr/share/quilt/delete
  /usr/share/quilt/delete: Bourne-Again shell script, ASCII text executable