Bug#379176: E: foo: non-standard-toplevel-dir srv/ is policy not an error
Hi, On Saturday 22 July 2006 02:49, you wrote: By my reading of FHS 2.3, no Debian-supplied package should be installing files into /srv, since /srv is reserved for the local administrator for local data. The error message may not be accurate, but it looks to me like this still should be an error. Am I missing something? I don't think you are correct: In http://www.debian.org/doc/packaging-manuals/fhs/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM the last sentence about /srv says: --begin quote - Distributions must take care not to remove locally placed files in these directories without administrator permission. [20] [20] This is particularly important as these areas will often contain both files initially installed by the distributor, and those added by the administrator. --end quote - So, as I read it, /srv is clearly designed for files from the distribution and locally added ones. regards, Holger pgpQNIaZzhHOt.pgp Description: PGP signature
Bug#379176: E: foo: non-standard-toplevel-dir srv/ is policy not an error
Holger Levsen [EMAIL PROTECTED] writes: On Saturday 22 July 2006 02:49, you wrote: By my reading of FHS 2.3, no Debian-supplied package should be installing files into /srv, since /srv is reserved for the local administrator for local data. The error message may not be accurate, but it looks to me like this still should be an error. Am I missing something? I don't think you are correct: In http://www.debian.org/doc/packaging-manuals/fhs/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM the last sentence about /srv says: --begin quote - Distributions must take care not to remove locally placed files in these directories without administrator permission. [20] [20] This is particularly important as these areas will often contain both files initially installed by the distributor, and those added by the administrator. --end quote - So, as I read it, /srv is clearly designed for files from the distribution and locally added ones. How can that be reconciled with: The methodology used to name subdirectories of /srv is unspecified as there is currently no consensus on how this should be done. One method for structuring data under /srv is by protocol, eg. ftp, rsync, www, and cvs. On large systems it can be useful to structure /srv by administrative context, such as /srv/physics/www, /srv/compsci/cvs, etc. This setup will differ from host to host. Therefore, no program should rely on a specific subdirectory structure of /srv existing or data necessarily being stored in /srv. However /srv should always exist on FHS compliant systems and should be used as the default location for such data. I don't see any way that shipping files under /srv in a Debian package would be consistent with the second-to-last sentence above. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#379176: E: foo: non-standard-toplevel-dir srv/ is policy not an error
Hi, On Saturday 22 July 2006 17:35, you wrote: How can that be reconciled with: The methodology used to name subdirectories of /srv is unspecified as there is currently no consensus on how this should be done. One method for structuring data under /srv is by protocol, eg. ftp, rsync, www, and cvs. On large systems it can be useful to structure /srv by administrative context, such as /srv/physics/www, /srv/compsci/cvs, etc. This setup will differ from host to host. Therefore, no program should rely on a specific subdirectory structure of /srv existing or data necessarily being stored in /srv. However /srv should always exist on FHS compliant systems and should be used as the default location for such data. I don't see any way that shipping files under /srv in a Debian package would be consistent with the second-to-last sentence above. I do. But I think this is getting out of scope of this bug :) Maybe the FHS should be reworded, but definitly linda should not announce this as an error. apache might ship with DocumentRoot in /srv/www - but apache must also work, if you modify this. You might have many DocumentRoots, in /srv/webserver/foo and in /srv/webserver/foo2... It says no program should rely on a specific subdirectory structure of /srv, not no program should rely on a specific directory in /srv - especially if you define this directory in the programms configuration. regards, Holger pgp5iiLMexvqT.pgp Description: PGP signature
Bug#379176: E: foo: non-standard-toplevel-dir srv/ is policy not an error
Holger Levsen [EMAIL PROTECTED] writes: On Saturday 22 July 2006 17:35, you wrote: How can that be reconciled with: The methodology used to name subdirectories of /srv is unspecified as there is currently no consensus on how this should be done. One method for structuring data under /srv is by protocol, eg. ftp, rsync, www, and cvs. On large systems it can be useful to structure /srv by administrative context, such as /srv/physics/www, /srv/compsci/cvs, etc. This setup will differ from host to host. Therefore, no program should rely on a specific subdirectory structure of /srv existing or data necessarily being stored in /srv. However /srv should always exist on FHS compliant systems and should be used as the default location for such data. I don't see any way that shipping files under /srv in a Debian package would be consistent with the second-to-last sentence above. I do. But I think this is getting out of scope of this bug :) I don't; I think it's exactly the point. apache might ship with DocumentRoot in /srv/www - but apache must also work, if you modify this. You might have many DocumentRoots, in /srv/webserver/foo and in /srv/webserver/foo2... It says no program should rely on a specific subdirectory structure of /srv, not no program should rely on a specific directory in /srv - especially if you define this directory in the programms configuration. Yes, and if you ship files in /srv, then your package is creating and insisting upon a particular structure in /srv. Even if the binaries in the package don't insist, the *package* is insisting. If the local administrator decides they want to organize /srv differently, your files get in the way. If they delete them or move them, every time the package is upgraded, they're re-installed. To me, that seems to break the point that the above paragraph is driving at. Certainly, I can see shipping configuration that points to /srv for local data by default, and even a postinst that creates an initial structure in /srv for the package if this is the first install, but putting the files directly in the package seems to me to be forcing more structure than is allowed here. Maybe we should take this to debian-policy and see what other folks think? I could be wrong and I'm happy to change lintian accordingly if the consensus is that I'm wrong. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#379176: E: foo: non-standard-toplevel-dir srv/ is policy not an error
Hi, On Saturday 22 July 2006 18:34, you wrote: Yes, and if you ship files in /srv, then your package is creating and insisting upon a particular structure in /srv. Even if the binaries in the package don't insist, the *package* is insisting. Yup. That's a structure my package created. Obviously I can depend on that. This is different to a structure the FHS mandates, like for example in /var: in /var you can rely on /var/lib, /var/log, ... - there is no such structure the FHS mandates for /srv. That's what is ment with that sentence. If the local administrator decides they want to organize /srv differently, your files get in the way. If they delete them or move them, every time the package is upgraded, they're re-installed. To me, that seems to break the point that the above paragraph is driving at. Not to me :) I agree it's annoying, but it's the same as today with say, /var/www. If I delete it, because I use /srv/www, an upgrade of apache recreates that directory, while it doesnt change my config. Certainly, I can see shipping configuration that points to /srv for local data by default, and even a postinst that creates an initial structure in /srv for the package if this is the first install, but putting the files directly in the package seems to me to be forcing more structure than is allowed here. So you agree that the lintian error is wrong :) Maybe we should take this to debian-policy and see what other folks think? Sure. Go ahead. And thanks for caring! I could be wrong and I'm happy to change lintian accordingly if the consensus is that I'm wrong. Obviously I could be wrong as well... ;) regards, Holger pgpl46wppJEQV.pgp Description: PGP signature
Bug#379176: E: foo: non-standard-toplevel-dir srv/ is policy not an error
Holger Levsen [EMAIL PROTECTED] writes: On Saturday 22 July 2006 18:34, you wrote: Yes, and if you ship files in /srv, then your package is creating and insisting upon a particular structure in /srv. Even if the binaries in the package don't insist, the *package* is insisting. Yup. That's a structure my package created. Obviously I can depend on that. And the FHS says that you're not allowed to do that. So... lintian is correct, I think. Certainly, I can see shipping configuration that points to /srv for local data by default, and even a postinst that creates an initial structure in /srv for the package if this is the first install, but putting the files directly in the package seems to me to be forcing more structure than is allowed here. So you agree that the lintian error is wrong :) None of those things would trigger a lintian error. :) Maybe we should take this to debian-policy and see what other folks think? Sure. Go ahead. And thanks for caring! Okay, will do. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#379176: E: foo: non-standard-toplevel-dir srv/ is policy not an error
package: lintian version: 1.23.22 Hi, the new version of policy mandates FHS 2.3, which requires /srv, so this is clearly no error :-) regards, Holger pgpgcKg6kzDZx.pgp Description: PGP signature
Bug#379176: E: foo: non-standard-toplevel-dir srv/ is policy not an error
Holger Levsen [EMAIL PROTECTED] writes: package: lintian version: 1.23.22 Hi, the new version of policy mandates FHS 2.3, which requires /srv, so this is clearly no error :-) By my reading of FHS 2.3, no Debian-supplied package should be installing files into /srv, since /srv is reserved for the local administrator for local data. The error message may not be accurate, but it looks to me like this still should be an error. Am I missing something? -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
