Control: tags -1 + moreinfo Hello Andreas,
On Thu, Dec 06, 2018 at 02:13:28AM +0100, Andreas Beckmann wrote: > Package: mender-client > Version: 1.6.0b1+git20181015.3032b74-1 > Severity: serious [...] > 0m34.2s ERROR: FAIL: Broken symlinks: > /var/lib/mender -> /data/mender (mender-client) > > If the target would be created, it would violate the FHS. It is my understanding that the system administrators are allowed to create any top level directories they want and FHS is perfectly fine with that. I assume you have no immediate knowledge of how mender works or even what it is. It's an embedded system (Over-the-Air) update service. It makes a few assumptions that can be described as "embedded industry standards" when it comes to handling updates somewhat securely. One of these is a particular partition layout, which needs to contain atleast DUAL root partitions and a persistent data area. (Mender also needs a patched u-boot to work, so there are several things the person integrating mender into their system needs to do after/before installing the package.) A *recommendation* is that the persistent data area is mounted under /data, but the integrator is free to mount it whereever they want (and then configure it themselves). The broken symlink is shipped so that mender itself can use a FHS path for accessing the persistent data (without knowing or caring much where the integrator chose to mount that partition). ie. it exists for the convenience of the integrators who choose to follow the recommendations from upstream. I could remove the symlink and patch the code to directly access the persistent data area without using an FHS path, but IMHO that would be a regression w.r.t. following the FHS - not an improvement. I could also just not ship the symlink and putting the burden on the integrators to figure it out themselves, but I don't think that's a good idea which would make people think debian is a good base either. Unless you reconsider after this information (if so please close the bug report), I guess I have little option but to ask the relevant debian entity group (tech-ctte, policy, release-team) about their view on this. Either way, I'd like to hear how you think I should continue. Regards, Andreas Henriksson
