One: Compiler FE: Debian package installation directory

[mhs4670go]

Yesterday we discussed about the directory name in Release TF meeting. And it was concluded that /usr/local/share/one would be better for these files. Please update the file location in the next patch. :)

_Originally posted by @jyoungyun in https://github.com/Samsung/ONE/pull/6755#discussion_r629799844_

Actually, when we build the debian package that installs binaries in /usr/local/share/one, an error happened.

$ cd ONE
$ debuild -us -uc -b
...
    install -p -m0644 debian/copyright debian/one-compiler-test/usr/share/doc/one-compiler-test/copyright
   dh_installchangelogs
    install -p -m0644 debian/changelog debian/one-compiler/usr/share/doc/one-compiler/changelog
    install -p -m0644 debian/changelog debian/one-compiler-dev/usr/share/doc/one-compiler-dev/changelog
    install -p -m0644 debian/changelog debian/one-compiler-test/usr/share/doc/one-compiler-test/changelog
   dh_perl
   dh_usrlocal
dh_usrlocal: debian/one-compiler/usr/local/share/one/lib/libluci_profile.so is not a directory
dh_usrlocal: debian/one-compiler/usr/local/share/one/lib/libluci_interpreter.so is not a directory
dh_usrlocal: debian/one-compiler/usr/local/share/one/lib/libluci_partition.so is not a directory
dh_usrlocal: debian/one-compiler/usr/local/share/one/lib/libluci_export.so is not a directory
dh_usrlocal: debian/one-compiler/usr/local/share/one/lib/libloco.so is not a directory
dh_usrlocal: debian/one-compiler/usr/local/share/one/lib/libluci_env.so is not a directory
dh_usrlocal: debian/one-compiler/usr/local/share/one/lib/libluci_import.so is not a directory
dh_usrlocal: debian/one-compiler/usr/local/share/one/lib/libluci_pass.so is not a directory
dh_usrlocal: debian/one-compiler/usr/local/share/one/lib/libluci_log.so is not a directory
dh_usrlocal: debian/one-compiler/usr/local/share/one/lib/libluci_logex.so is not a directory
dh_usrlocal: debian/one-compiler/usr/local/share/one/lib/libluci_lang.so is not a directory
dh_usrlocal: debian/one-compiler/usr/local/share/one/lib/libluci_service.so is not a directory
    rmdir debian/one-compiler/usr/local/share/one/lib
rmdir: failed to remove 'debian/one-compiler/usr/local/share/one/lib': Directory not empty
dh_usrlocal: rmdir debian/one-compiler/usr/local/share/one/lib returned exit code 1
debian/rules:8: recipe for target 'binary' failed
make: *** [binary] Error 1
dpkg-buildpackage: error: fakeroot debian/rules binary subprocess returned exit status 2
debuild: fatal error at line 1152:
dpkg-buildpackage -rfakeroot -us -uc -ui -b failed

It can be solved by letting dh_usrlocal do nothing.

$ cat debian/rules
...
override_dh_usrlocal:
    # DO NOTHING

As guide said, do not use /usr/local directory. And, this is related Q&A.

Most third-party software installs itself in the /usr/local directory hierarchy. On Debian this is reserved for private use by the system administrator, so packages must not use directories such as /usr/local/bin but should instead use system directories such as /usr/bin, obeying the Filesystem Hierarchy Standard (FHS).

Well, I'm not sure you guys(@jyoungyun, @seanshpark) might have considered this, but, just in case, I'm writing this issue for your information.

[seanshpark]

Thanks for the info!.
I'v not much knowledge but we can think of adding links like, sym-links from files in one/lib to usr/local/lib and one/bin to usr/local/bin...

[seanshpark]

libluci_profile.so is not a directory

hum.. :)

[mhs4670go]

@seanshpark

libluci_profile.so is not a directory

It is just one of dh_usrlocal's action.

$ man dh_usrlocal
...
`dh_usrlocal` finds subdirectories of usr/local in the package build directory, and removes them, 
replacing them with maintainer script snippets ...

---

sym-links from files in one/lib to usr/local/lib and one/bin to usr/local/bin...

This sym-link things can be achieved with maintainer scripts. But, as https://www.debian.org/doc/debian-policy/ch-opersys.html#s9.1.2 said,

As mandated by the FHS, packages must not place any files in /usr/local, either by putting them in the file system archive to be unpacked by dpkg or by manipulating them in their maintainer scripts.

However, the package may create empty directories below /usr/local so that the system administrator knows where to place site-specific files.

In short, dh_* tools do not support packages being installed in /usr/local directory.

Well, we can just ignore the debian guide. Or just installing in usr/ is possible as well.

[seanshpark]

Well, we can just ignore the debian guide. Or just installing in usr/ is possible as well.

@lemmaa PTAL
yesterday, in off-line meeting @lemmaa suggested to install in /usr/local but seems not official(?) way...

+1 for using usr/ as our target :)

[lemmaa]

@lemmaa PTAL
yesterday, in off-line meeting @lemmaa suggested to install in /usr/local but seems not official(?) way...

+1 for using usr/ as our target :)

@mhs4670go, @seanshpark , I have recommended /usr/local/share/one from past _dotnet_ experience. But when I checked today, the thing that _dotnet_ used was /usr/share/dotnet. My memory was wrong. You can go to /usr/share/one. Sorry for the confusion.

/cc @jyoungyun

[jyoungyun]

I'm looking at this issue and found several guidelines about it.

As mandated by the FHS, packages must not place any files in /usr/local, either by putting them in the file system archive to be unpacked by dpkg or by manipulating them in their maintainer scripts.

from here

No other directories, except those listed below, may be in /usr/local after first installing a FHS-compliant system.

from here
This file is the latest FHS(Filesystem Hierachy Standard) version.

4.11. /usr/share : Architecture-independent data
4.11.1. Purpose
The /usr/share hierarchy is for all read-only architecture independent data files. [30]

This hierarchy is intended to be shareable among all architecture platforms of a given OS; thus, for example, a site with i386, Alpha, and PPC platforms might maintain a single /usr/share directory that is centrally-mounted. Note, however, that /usr/share is generally not intended to be shared by different OSes or by different releases of the same OS.

Any program or package which contains or requires data that doesn't need to be modified should store that data in /usr/share (or /usr/local/share, if installed locally). It is recommended that a subdirectory be used in /usr/share for this purpose.

You can go to /usr/share/one.

I agree to use the proper location /usr/share/one.

I will update the npu-compiler files too.

[mhs4670go]

The /usr/share hierarchy is for all read-only architecture independent data files.

Technically, one binaries are not architecture independent data files but I'll follow the decision.

Anyway, I heard that after /usr/share/one is installed, the binaries are sym-linked to /usr/lib and /usr/bin. Is it right?

[seanshpark]

Anyway, I heard that after /usr/share/one is installed, the binaries are sym-linked to /usr/lib and /usr/bin. Is it right?

Yes, we had discussion like this :)

• personally not sure this is debian recommanded way but let's give it a try

[jyoungyun]

Technically, one binaries are not architecture independent data files but I'll follow the decision.

I also confused about it. But when I search for the guideline about architecture-dependent modules, I can't find clear document.

Anyway, I heard that after /usr/share/one is installed, the binaries are sym-linked to /usr/lib and /usr/bin. Is it right?

Maybe we should do that.

[mhs4670go]

@jyoungyun

I also confused about it. But when I search for the guideline about architecture-dependent modules, I can't find clear document.

I think both of architecture-dependent and independent binaries and libraries are supposed to be located in /usr/bin or /usr/lib. It is data files that is supposed to be /usr/share rather than binaries or libraries.

---

FYI, as guide said, when the package has become architecture-independent, it looks like below.

What does the end result look like?

/usr/lib -> /usr/lib/<triplet>
/usr/lib/<pkgdir> -> /usr/lib/<triplet>/<pkgdir>
/usr/include: remains, used for arch-independent headers
/usr/include/<triplet>: used for arch-varying headers 
/usr/bin: no change
/usr/share: no change
/usr/sbin: no change

Here, <triplet> is a value that is taken from the CMAKE_LIBRARY_ARCHITECTURE variable like x86_64-linux-gnu.

[mhs4670go]

Well, anyway, since one-prepare-venv should be run when one-compiler is installed for venv, share or sth is needed.

one-compiler.tar.gz
This is the built packages that above decision is applied to. As of now, it can't be run because of sym-link problem T_T. I'll find the solution..