Bug#750255: lio-utils: FTBFS: chmod: cannot access '/«BUILDDIR»/lio-utils-3.1+git2.fd0b34fd/debian/lio-utils/usr/share/pyshared/*.py': No such file or directory

[Jerome Martin]

Hi Ritesh,

By the way, are there plans on fixing this ?
E: python-rtslib: non-standard-dir-in-var var/target/
W: python-rtslib: file-in-unusual-dir var/target/fabric/ib_srpt.spec
W: python-rtslib: file-in-unusual-dir var/target/fabric/iscsi.spec
W: python-rtslib: file-in-unusual-dir var/target/fabric/loopback.spec
W: python-rtslib: file-in-unusual-dir var/target/fabric/qla2xxx.spec
W: python-rtslib: file-in-unusual-dir var/target/fabric/tcm_fc.spec
W: python-rtslib: file-in-unusual-dir var/target/fabric/usb_gadget.spec
I have added a lintian override for now. From what I recall, we didn't
want to change it because this same path was consumed in the kernel
component of LIO.

Yes, the problem is that the kernel side uses this path unfortunately.
We could relocate policy and fabric to /var/lib/target, but that would
mean keeping both /lib/target and /var/target around for now, as the
kernel will use that for storing alua metadata in /var/target/alua.

However, what about relocating now, and keeping around a symlink to
/var/target, created in post-install?

This way, as soon as Nic can push the relocation to /var/lib/alua, we
are ready and just have to remove the symlink from packaging.

I am cc'ing the ML on this one.

Best,
--
Jerome

[Ritesh Raj Sarraf]

Post by Jerome Martin
Yes, the problem is that the kernel side uses this path unfortunately.
We could relocate policy and fabric to /var/lib/target, but that would
mean keeping both /lib/target and /var/target around for now, as the
kernel will use that for storing alua metadata in /var/target/alua.
However, what about relocating now, and keeping around a symlink to
/var/target, created in post-install?
This way, as soon as Nic can push the relocation to /var/lib/alua, we
are ready and just have to remove the symlink from packaging.
I am cc'ing the ML on this one.

The manpage, written by Andy, refers to /var/lib/. Which would imply
that Fedora/RHEL and all its derivatives must be using the new path.

[Andy Grover]

Post by Ritesh Raj Sarraf

Post by Jerome Martin
Yes, the problem is that the kernel side uses this path unfortunately.
We could relocate policy and fabric to /var/lib/target, but that would
mean keeping both /lib/target and /var/target around for now, as the
kernel will use that for storing alua metadata in /var/target/alua.
However, what about relocating now, and keeping around a symlink to
/var/target, created in post-install?
This way, as soon as Nic can push the relocation to /var/lib/alua, we
are ready and just have to remove the symlink from packaging.
I am cc'ing the ML on this one.

The manpage, written by Andy, refers to /var/lib/. Which would imply
that Fedora/RHEL and all its derivatives must be using the new path.

I don't see any mention of /var/lib. In any case, RH packaging isn't
creating /var/target/{alua,pr} directories, whose absence will cause PR
ops to fail in 3.11+-based kernels even if they don't use APTPL. I need
to fix that soon.

If I came up with a kernel patch that made the path that ALUA & PR files
were written to settable via configfs, would that also be helpful to you?

Nick, thoughts?

Regards -- Andy