Accepted python-fhs 1.2-1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 19 Feb 2023 02:34:47 +0100 Source: python-fhs Architecture: source Version: 1.2-1 Distribution: unstable Urgency: medium Maintainer: Bas Wijnen Changed-By: Bas Wijnen Changes: python-fhs (1.2-1) unstable; urgency=medium . * Update Standards-Version to 4.6.2. No changes needed. * Set Multi-Arch: foreign. * Update doxygen configuration. * Add package tests. Checksums-Sha1: 751f7ca92f618b4b4a879ad31667769159f98210 1905 python-fhs_1.2-1.dsc f86473a32d72d8be5c96dd6e60dedb7f361aa312 41970 python-fhs_1.2.orig.tar.gz 8232b69f68e09cdfbcc2b4ac84d9c0ae174dcc0b 13724 python-fhs_1.2-1.debian.tar.xz Checksums-Sha256: f9ecdd2034a8094d84c9a1412eb0910a7aa247dfd5b7031cc8305a7d462ee322 1905 python-fhs_1.2-1.dsc 97c1af9df6c7c571201be5e1ab7a033e30ffe01a394504765bc17da4d1be701b 41970 python-fhs_1.2.orig.tar.gz bd89350bdb015bb534c5df467af45a7e6d83d4e469a7ca6547e932254c3e33be 13724 python-fhs_1.2-1.debian.tar.xz Files: 2485c2d420de40875c3e7fa1adc1ca53 1905 python optional python-fhs_1.2-1.dsc 2a6a104d8fb1cd552f8446e70493fd82 41970 python optional python-fhs_1.2.orig.tar.gz 9e55e764c7f74bab444c3dc3038513d2 13724 python optional python-fhs_1.2-1.debian.tar.xz -BEGIN PGP SIGNATURE- iQJGBAEBCgAwFiEEKI9JSvHOfJKJyDQanNF9WAfAcToFAmPxffMSHHdpam5lbkBk ZWJpYW4ub3JnAAoJEJzRfVgHwHE6vB8P/2L7oT6ZKFi1u0zaam3yXkBykgeW7DnO RL5llfS2uxQW1U4mNAEtjZddD9pxTqKTVXNFg/Fpkn0R4Pbhmf1hJq3+gYzqAS2w JJ0pq3fPt1Pwqkzn4MAAkFtAKcD91jQJzEGOyjskHOWv2WcPZxJykPVtlQT6TIA8 i4ouEGOGE/5HsLoC/U+6dCDGxBxT9/mUuLlFv3Uon2qydSK7nW3a0HXvAy1DB4Vt OWAnV/JLCJ1v679mVoBlKK2suhkjIDF1SF9dN/g8JzHHY/AqaTw70EhIIPvb4cyb WtNtU3ZNsmn/TXF5UOM4pzP42+MmlOYq8Q/aYONS8F9OmtnRF48ise2OCyfG/VXn PLcvT42akNHN5gdIbfpMoDnUCv0kFlYlkIWgYYL/duAiPMvzcbvoAvN+is1UnQjs 3ZMnlbmGdBGNphkd5bEiy4mhAP1X8bF6go+O2+q4Fmc2x4h1ouyXg+Bi0xA45L9I 1AQRv8lvUqPplih2wmAzlOOs6J2eEnIqQ8RLukzClJaDkj1ByQS0ZoeoXIEX4sj8 d/dTacIVTX7MHTmVW7TlpuMsYwGO7csGZCt44s5DdxvhZHsQTAiMkrPUXh+0aeYM bqKWau/BJ7S7gIYtePuGxOMS8Ae0EBNgE0OPXXFLRhWfNpWkW/bYqTaZK/WDcLYC G8WMrcAOCF+1 =yrN6 -END PGP SIGNATURE-
Accepted golang-github-fhs-gompd 2.3.0-1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Mon, 24 Oct 2022 17:23:44 + Source: golang-github-fhs-gompd Architecture: source Version: 2.3.0-1 Distribution: unstable Urgency: medium Maintainer: Debian Go Packaging Team Changed-By: Martin Dosch Changes: golang-github-fhs-gompd (2.3.0-1) unstable; urgency=medium . * New upstream release. Checksums-Sha1: 456a6560da3b2c877a65eddcc62033283ed2d2b7 2220 golang-github-fhs-gompd_2.3.0-1.dsc 8ea4ffac30326f8000b35a6447bcca996b43158c 24742 golang-github-fhs-gompd_2.3.0.orig.tar.gz 4f436df08c60274ba4054e748c5d9f1eedef4896 2388 golang-github-fhs-gompd_2.3.0-1.debian.tar.xz e187c1d5866e4dc0fb0561fef48f0a998f9ffc31 6106 golang-github-fhs-gompd_2.3.0-1_amd64.buildinfo Checksums-Sha256: 5947a3908f62177ada8061cbf10bd3a0903af0925c74b83d71faa4b28c7a6494 2220 golang-github-fhs-gompd_2.3.0-1.dsc 049e057982b29f09c81b84520515120b243aa300bbef4cbe0183090fd2de929e 24742 golang-github-fhs-gompd_2.3.0.orig.tar.gz 12bdd7a817ead15009c63264f5900792b8f4ffe9d77e27a79ba7f4433366516f 2388 golang-github-fhs-gompd_2.3.0-1.debian.tar.xz dbf5d0f5a6752d3bbda950073298bf4dda2dc7f38b12a88cbfbcc3b9d3f991e8 6106 golang-github-fhs-gompd_2.3.0-1_amd64.buildinfo Files: ec308537abdfca62ee7dac88c07bbb95 2220 devel optional golang-github-fhs-gompd_2.3.0-1.dsc 35731c6f0d6bc218a3547dc8e763046b 24742 devel optional golang-github-fhs-gompd_2.3.0.orig.tar.gz c62fab80ab1ff5fd045ee6a1e2c9fee3 2388 devel optional golang-github-fhs-gompd_2.3.0-1.debian.tar.xz f4555e0c38086eca01c2480c26599319 6106 devel optional golang-github-fhs-gompd_2.3.0-1_amd64.buildinfo -BEGIN PGP SIGNATURE- iQJFBAEBCgAvFiEE/VqS9CCBN6S2aAs9UqV8/OE9ZX0FAmNW0dcRHG1hcnRpbkBt ZG9zY2guZGUACgkQUqV8/OE9ZX1Exw/8DbwAhkFj0a+3aXVAu063uei3CTzbo9S3 7LJr2zCJO5jbfEfR5vWW2H2L0K8vJ/s3NQVGcfZHCLT8ZSXXDSL/LvKrSbqx3HwK nZ63L8kA1v6X71ehCYdcECrNXv45x85QjOyAPVtD4qxAtVV3sl7KU4ZNwGusxGXO Ccji9X5n8siAv+QYV9BvxG3BR2iqavvCYVi9zHKKmGnpBM+xseaQ37sl7YosstSF O6E9sraH9F3+ktjDdscUblbhoFqLDxE0GOg0N31kFO46SKQdw+Fe3xz6dsIF3NiB 6AL05O9zLGFK9TWFDyWabuYL1cd8pwmJYLxw5VTCX/hlf0CuHHAoWER2T5b/o5QJ k7T0EaC/J5samWF7y1spp7YaGeE0o4sIOYy0gIDklAr0iCeoDS/Gc2yR5U5C0JcZ jmSaCp/bpGF3OEHVEYjyug9KIpwjVKcjXelVRves1p7j/b9Kjp+GPBpXTCqwjK6u VWMBZ0Cvx1J6NyXGV2+AkiraYiVsKwGYXfgt1SnoXGS+2rmPtjdy/oE6f1Pf1e4i fYBXULcKdKBZBGzZ8bOtiXzns5L+nETJR8HeU2doYUecXLZwrq4QEdd9IEu/EoNg YD78A7Sqd0Lu60XiJogE953M8No/j7L8w2B37pkmIZG/cbbBhiU1606YLNfVyrel HYqypQzKy28= =ifby -END PGP SIGNATURE-
Accepted golang-github-fhs-gompd 2.2.0+git20220620.bbf8359-1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 09 Oct 2022 08:19:45 +0200 Source: golang-github-fhs-gompd Architecture: source Version: 2.2.0+git20220620.bbf8359-1 Distribution: unstable Urgency: medium Maintainer: Debian Go Packaging Team Changed-By: Martin Dosch Changes: golang-github-fhs-gompd (2.2.0+git20220620.bbf8359-1) unstable; urgency=medium . * Update to latest development version (required for ymuse). Checksums-Sha1: d7d5404d69e5b0b278e6ac0915df827ad4c1c3f9 2360 golang-github-fhs-gompd_2.2.0+git20220620.bbf8359-1.dsc d6d525fbb0eb37208ff187fa541ad0d0c93a352a 23640 golang-github-fhs-gompd_2.2.0+git20220620.bbf8359.orig.tar.gz 7e93e03e2f30c2c5a8aa4cbeb8167fb52750f228 2364 golang-github-fhs-gompd_2.2.0+git20220620.bbf8359-1.debian.tar.xz 34961e0fe377439b30c5c9418637a207be2c97ab 6160 golang-github-fhs-gompd_2.2.0+git20220620.bbf8359-1_amd64.buildinfo Checksums-Sha256: 09066c21498ab2d4d760f3ef958c52a7d8e888f100e19b9c50eb4d377e263525 2360 golang-github-fhs-gompd_2.2.0+git20220620.bbf8359-1.dsc b4954a737bd7846326330633907d9fcc27a00876ace5110c8dbc3f63157f28bf 23640 golang-github-fhs-gompd_2.2.0+git20220620.bbf8359.orig.tar.gz e3f97e007d237200d0227229d40e9a42c831bf1192edbeea24d811f57c09141a 2364 golang-github-fhs-gompd_2.2.0+git20220620.bbf8359-1.debian.tar.xz 955350d6b8f8b8f6b0b29446da86ce80a1f45697fb1629fb1a17c456f4b45a08 6160 golang-github-fhs-gompd_2.2.0+git20220620.bbf8359-1_amd64.buildinfo Files: c7cb8cef9b00bf3ed3c2bf3730c224c9 2360 devel optional golang-github-fhs-gompd_2.2.0+git20220620.bbf8359-1.dsc 92eb9c7fa965dc7ef3b90397dc0e32ef 23640 devel optional golang-github-fhs-gompd_2.2.0+git20220620.bbf8359.orig.tar.gz 0a6ba5a1f2664ce85334f46aa3e50782 2364 devel optional golang-github-fhs-gompd_2.2.0+git20220620.bbf8359-1.debian.tar.xz 92d8e392536cc752c4591018a0886728 6160 devel optional golang-github-fhs-gompd_2.2.0+git20220620.bbf8359-1_amd64.buildinfo -BEGIN PGP SIGNATURE- iQJFBAEBCgAvFiEE/VqS9CCBN6S2aAs9UqV8/OE9ZX0FAmNCaSsRHG1hcnRpbkBt ZG9zY2guZGUACgkQUqV8/OE9ZX2UNxAAtaqEsTtVWOzUkwOTWeZgwBI5t5iTpn09 lVVrY41AhXQLdioUkJcq3+dbHqT/+ba1YVWuUc1pxyMBi72IurBe2OYBXIPfrRfa bxPLE1PBWbVwQ2Jd8qukIvI8ePQTcospRvtdsRtlGoAt6vrb/1gi0XlS1qQqb/iU Wo4z8/z3x9GRPnC1eeXYl38sPVixibwGWZj2kb215WZqxVu9gh3InlVbkVkWCiCF +EnrpvyCFSMzwVVUMV0hUInq0w1ddSjv/tCEwjsmG9m23s526fXf1inyrI3nLYpD vll15D8SzT2of8UNrqjcSNbRGNCn/ddgLOPPn/2kaWN+uSRZtqMlG4g+XwKf0nT8 g1U6UgbYLUwTMB22nn2xfULPYUK/JvkLQuVSscir2rOsOquZddkWCvEoWap4HDyB uPY9QIjjzZJsJPSEhxAZ/1SuMZq9Prq1TdLnp8MJuJGh2E4piPX2x6VymMpcOJu+ Ui9R3KTA1NkoJSGUbXGi8P4kpwtVrQKBAz5bShxbZik9safY4ngJmL6AS9pZCbFt 6C0R3vS4GF93ymrM+9iSuGAemWhBwMMN9xvXS+dXSwdyTLNXAsX+dZbNBoKfR/5Q WUgXVSH87ELpCQajQBREAN7oSDfXzf7GfVmB2WgnrpHNAtZ49bniCLT2Xi3Q+RfY ByKTwlzT1wM= =qopa -END PGP SIGNATURE-
Accepted golang-github-fhs-gompd 2.2.0-1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Fri, 07 Oct 2022 15:09:13 +0200 Source: golang-github-fhs-gompd Architecture: source Version: 2.2.0-1 Distribution: unstable Urgency: medium Maintainer: Debian Go Packaging Team Changed-By: Martin Dosch Changes: golang-github-fhs-gompd (2.2.0-1) unstable; urgency=medium . [ Debian Janitor ] * Bump debhelper from old 11 to 12. * Set debhelper-compat version in Build-Depends. * Set upstream metadata fields: Bug-Database, Bug-Submit, Repository, Repository-Browse. * Update standards version to 4.5.0, no changes needed. * Apply multi-arch hints. + golang-github-fhs-gompd-dev: Add Multi-Arch: foreign. . [ Martin Dosch ] * Team upload * New upstream release. * debian/control: Bump standards version to 4.6.1, no changes needed. * debian/control: Bump debhelper-compat. Checksums-Sha1: 5ac1487987cd0a4a8c5ed48a0875d8f5e2b088ce 2187 golang-github-fhs-gompd_2.2.0-1.dsc 50512308e6cc684c40d42c5495ce5eedb4a902f6 24204 golang-github-fhs-gompd_2.2.0.orig.tar.gz 78c95a0d433fa00ab9cd24d29f54f19ef92815b4 2284 golang-github-fhs-gompd_2.2.0-1.debian.tar.xz b708c8fad59dd26ec2ee1e897d5cbefde24a3de1 6044 golang-github-fhs-gompd_2.2.0-1_amd64.buildinfo Checksums-Sha256: d172a45b566adb3c32c55a399c0fdef44ff28aa44c903e8926f9cc8a0ad86356 2187 golang-github-fhs-gompd_2.2.0-1.dsc f754cfecc3860c95cdae9e15beb9f0f911a165a97b276c4a1c9ffcf00de92d49 24204 golang-github-fhs-gompd_2.2.0.orig.tar.gz 221584d10ec4746268a64b4f06384303ee3478cd9eff4058eb8e87a959b2ba69 2284 golang-github-fhs-gompd_2.2.0-1.debian.tar.xz 2f803299313ce556e0bd2331432aac9dff42acbeb35e750c94b0d35b6c64dc65 6044 golang-github-fhs-gompd_2.2.0-1_amd64.buildinfo Files: 26d9938db2c4b5b9c4bb6c80be5342be 2187 devel optional golang-github-fhs-gompd_2.2.0-1.dsc 07c2746a80293c5244abffd1820df2f3 24204 devel optional golang-github-fhs-gompd_2.2.0.orig.tar.gz db7da8e1daf74571e1c900509695def0 2284 devel optional golang-github-fhs-gompd_2.2.0-1.debian.tar.xz b54ad694aa7c66063597690460b3fa5e 6044 devel optional golang-github-fhs-gompd_2.2.0-1_amd64.buildinfo -BEGIN PGP SIGNATURE- iQJFBAEBCgAvFiEE/VqS9CCBN6S2aAs9UqV8/OE9ZX0FAmNAJZ8RHG1hcnRpbkBt ZG9zY2guZGUACgkQUqV8/OE9ZX15GA//c+y77xXNlf3xd3hO63KT/nQsIkItDRNl 9ygyhdEILn4T5NftQTXXLB9k9vVlmxkG7cJuI+0C2Xg0I3LsFhi87AnqV3GxaWR8 7GC38vDAYdrLfKrkiYmmIyv6QSIK1OI6gNGfLr3UzMMnEXZPm8ucSHeRKpYIj9uA T/S0/995Ak0Zmx1kLJldyOqx8Osf14WVzffH357lUDYzbrIPDUXig2kPqMZQX48q L4JPLFlS0hb5FPRg4Ueg99sVPk4bGHM9uu+Yjq4FtNXv754EIyY0J9UnCnSl1jQo 3Nv2/uQDFJYUI51/rWWRacILDhjJv5PGvuENZMMeedKxCeu8pCuHiIYZdzbdj6aI JndmLZ2I/EAPOOq2qvKPHnJxUNc3YdeFhof2je7rh7OcQulZ7lYfDj6upy4RAvQT ehMym41Pm+teZkEZGxeUbYIFJqolVMkV8U9ai1RdLrntvmIQFB4t8dBeetH7fZZQ BthuQ1098ll/sgc8mTSbSi7UhgbUhNY1XbIM4Y22GndKW3olwUhuFIpx6Vwvsovs EOBVDhQ5OjcR6aYbawf/5RukM37SilsBX2rVyKvSuv/uWyspWsLzfsgiwAjItlwG 8DY1Vzgx49b22l5zJ7oy6jd8Nf5mmgTot0PufgifGH8iNoVIB9Yf0KH70ouTMs1E lFLVplGaEFM= =+6uu -END PGP SIGNATURE-
Accepted python-fhs 1.1-1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Tue, 31 May 2022 12:49:11 +0200 Source: python-fhs Architecture: source Version: 1.1-1 Distribution: unstable Urgency: medium Maintainer: Bas Wijnen Changed-By: Bas Wijnen Changes: python-fhs (1.1-1) unstable; urgency=medium . * Clean up build system. * Update standards version to 4.6.1. No changes needed. Checksums-Sha1: 71942369d30593e6d63cffc480eb7b3dd60f4eb7 1882 python-fhs_1.1-1.dsc 8fc1224b9b51f78ad4f8d0115d0fa629fd972a7f 40747 python-fhs_1.1.orig.tar.gz 0f6a8c7885a88dbdbd92273adeeccf4d9c5f117f 12368 python-fhs_1.1-1.debian.tar.xz Checksums-Sha256: f81ca6498de7abc51514fe724e17d4901dfc97e8de3dfe85b8bc5be079ceb92f 1882 python-fhs_1.1-1.dsc 0bdcc7482ef624f1f348a288a5d7831e62005209f37a9229e6c47483cf38a024 40747 python-fhs_1.1.orig.tar.gz e13dee56fd56d2f792e75897af998842bcef06adbdeb864b410a0c54db86ce0f 12368 python-fhs_1.1-1.debian.tar.xz Files: e6e4f10d3d98823e4c125e69a82ca109 1882 python optional python-fhs_1.1-1.dsc d98ca9fb52ae07c7826c125f7c985aa0 40747 python optional python-fhs_1.1.orig.tar.gz a5d9478b59ffd110b454189b0f6a2097 12368 python optional python-fhs_1.1-1.debian.tar.xz -BEGIN PGP SIGNATURE- iQJGBAEBCgAwFiEEKI9JSvHOfJKJyDQanNF9WAfAcToFAmKV824SHHdpam5lbkBk ZWJpYW4ub3JnAAoJEJzRfVgHwHE6BNsP/2BFvDyyhx2BsgAoY6Vyk4k6MiCVme1s WBB8SBMSXNji5wfGXGNHU8nJ61/hq1h8+LHb/Qu9o8EXt+htEvaPMP+vDJbTy1LS hQvnlTREKITO8RjXvmaDAN9NqlEYZbiSHd2oOWCiL+J/MXgG2afo8J7dkUUpIXuH HGDkWoUEKgDJux/RTTU21HBGQdwPo05nt6P3dFb0Ar6CHTRpwyjMJ//U1BKoNv0g lefCQGLBgHKhCA1nHOWjPNXWjspwK4oak50IsBCeh2UIbLmncxtSXxx++8JCYC7a BbP4TBkyqS6OOvob54qgxnsHmg2yLV5mHnwKz85XFYwgFNdS1T7iw50B2c5cyKaO h9pFqMnwprYRoqFOfUQjKpDt0/wjSaS1bzNacHvShivCCp9u1K4lMEWHwKIA4CZo 2S4QYmF920FUWcjNJNuAZnRvtGLmhPth7qEmEtS8Qg+eB16OmOVZYUSATlA9QUsH ehCqokCxYxFQAh3WPVfS6rVofYhK4nPvfb+4AcxO+54EonSHHJIzNbHJrTnslaWy qfkcnWyosY+DAyXyYz9SVrhYqjn9g1qHkuXxzNzVu5CiiQ1+pPqmTDlhCbNYDIpT qVvlmD8EaTNrUJQVBNQBIuGuTNzsOJJ4NnpADaMgYzngk11q9EXszSDmiH22Seyh Szz4wn4A0kmw =e5wK -END PGP SIGNATURE-
Accepted python-fhs 1.0-1 (source all) into unstable, unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Fri, 22 Apr 2022 11:57:10 +0200 Source: python-fhs Binary: python3-fhs python3-fhs-doc Architecture: source all Version: 1.0-1 Distribution: unstable Urgency: medium Maintainer: Bas Wijnen Changed-By: Bas Wijnen Description: python3-fhs - python module for using the FHS and XDG basedir paths. python3-fhs-doc - API documentation for python3-fhs Closes: 1010010 Changes: python-fhs (1.0-1) unstable; urgency=medium . * New release. * Upload to Debian. Closes: #1010010 Checksums-Sha1: 565c99a2b4751eea5172a106e5406e74950fa402 1882 python-fhs_1.0-1.dsc 1b44d7d5179af5b2fb00d9143901228730674b9e 90665 python-fhs_1.0.orig.tar.gz 54ae4312585805b0a3d6bf5ae40894d0d6d701c3 12284 python-fhs_1.0-1.debian.tar.xz 338e0d0625ff15d25a7824aa475d734e6bf98342 9362 python-fhs_1.0-1_amd64.buildinfo 52b50c29b0a7b363316f25ec85845c0bb7885178 337456 python3-fhs-doc_1.0-1_all.deb d7c72896853683ddda8ef64b3abc97596700869c 22664 python3-fhs_1.0-1_all.deb Checksums-Sha256: 73b706aa6a581e641fe2f4c747a5c532b5816008d055a40c96fd7d494ffa99a5 1882 python-fhs_1.0-1.dsc 1cc5e26a0fceb3fa5ed61859abafa0207f8e20402bb372cfc3a5e1888ce7ca32 90665 python-fhs_1.0.orig.tar.gz 46c8aef4cc93cd4b6fb8f4f587940c8a133b8da7996a51a3bc941822f0f05233 12284 python-fhs_1.0-1.debian.tar.xz 9c7477596d6350b8ad93e056810c8ca0d4f0a157ae8e43451cd794c6c308aacf 9362 python-fhs_1.0-1_amd64.buildinfo 384c6899b29bd6b6869c561758b10c50765ffb6c0faf11e2fb017b46ad9f1a8b 337456 python3-fhs-doc_1.0-1_all.deb 748f37465e664b975a71eb2ab1a8ea06b76cfc7dcc7ec8c5fac60f54362ce4a2 22664 python3-fhs_1.0-1_all.deb Files: 8e22832c7032c775b94fa438dd02f0d3 1882 python optional python-fhs_1.0-1.dsc 65f22ec801e9f80096103c31184a19fd 90665 python optional python-fhs_1.0.orig.tar.gz aa7011ebe5bb234e61e2d04a9eddcdd9 12284 python optional python-fhs_1.0-1.debian.tar.xz 5b4dd9a7265a057bb482239f8c288cbc 9362 python optional python-fhs_1.0-1_amd64.buildinfo 33d51e4c444e383a3daca288e93b457e 337456 doc optional python3-fhs-doc_1.0-1_all.deb 06201e7765953242057809a8ed3fce21 22664 python optional python3-fhs_1.0-1_all.deb -BEGIN PGP SIGNATURE- iQJGBAEBCgAwFiEEKI9JSvHOfJKJyDQanNF9WAfAcToFAmJihqgSHHdpam5lbkBk ZWJpYW4ub3JnAAoJEJzRfVgHwHE65FwP/j/FzOlf6FSCNRdo8+vHToNbsXbGEIcx 5nolufHAZOH9GYmRulTCt3y5VY7VB6njncGWedwYRyXat2Q6O8e/GXpJVi9y0flF 2TA6+U8EUJasBaZz047QXqS2vprQ9HAVH60PXBoaHKj5p9zovw48RLuD2LLV8TJn kqfC7P8RnyVrQ/NKZRzF5fN3JYhOsKsco8uIjCsrr2SxD5db/Uos21uPyVb9pQEv XWOH7NDe/zXBbvl8vg1o30wEMTcBNUZjS475QDGQwcH4fPl+jSdABNXMsKsZkJnu XpLimfPlMQHB9gZ9iXApDkONMUkMEvyyWBzUVmmW78kcFapygv8g8TS8cgzEe1Bf Dv96ljuQXMSSCAQnKlnAL7hKDAHmyQjeuI5MApF5Y6Dh+eHTwKjwZV129UgvQvUc yeex0fd80tY6uZontGomr3yk31M9WigMjW+rtLOTNoy5gMvuJhki81wQrABEzHq7 4gy9QaJyfF7w/CCi3HynwDW8YVboMdNE7R0WJ0z48hL6t46jgiwh30zMbSOhZBtP k89MOxx1bTViqHSo8soJtI/snrsKFfF4hAQZYKgqngiSCsbSDtZtxGS//atcBUAz ZNRXyQ2GOct3zrM7hdotkk5s7Y/fVf95x9lt89nUgI+B2LXIdfEfAaAH3oKq1Qpn yzEjEsrRGymu =wqQG -END PGP SIGNATURE-
Bug#1010010: ITP: python-fhs -- Python module for using the FHS and XDG basedir paths.
Package: wnpp Severity: wishlist Owner: Bas Wijnen X-Debbugs-Cc: debian-devel@lists.debian.org, wij...@debian.org * Package name: python-fhs Version : 1.0 Upstream Author : Bas Wijnen * URL : https://github.com/wijnen/python-fhs * License : AGPL3+ Programming Lang: Python Description : Python module for using the FHS and XDG basedir paths. The FHS and XDG basedir specification defines locations for several files. This module provides functions for accessing those files without requiring the program to search the filesystem itself. It provides a convenient way to use configuration from files, with commandline override functionality. I use this for most of my Python programs. It is also depended on by python-network and python-websocketd, which I will file an ITP for after this.
Accepted golang-github-fhs-go-netrc 1.0.0-3 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sat, 06 Feb 2021 15:38:38 + Source: golang-github-fhs-go-netrc Architecture: source Version: 1.0.0-3 Distribution: unstable Urgency: medium Maintainer: Debian Go Packaging Team Changed-By: Jelmer Vernooij Changes: golang-github-fhs-go-netrc (1.0.0-3) unstable; urgency=medium . [ Debian Janitor ] * Use secure copyright file specification URI. * Set upstream metadata fields: Bug-Database, Bug-Submit, Repository, Repository-Browse. * Update standards version to 4.4.1, no changes needed. Checksums-Sha1: e25f736719d079f8335cbe99cadbc158369771c1 2189 golang-github-fhs-go-netrc_1.0.0-3.dsc 7ea7ecc8d46c45efe2a099a8797460aed3853039 3288 golang-github-fhs-go-netrc_1.0.0-3.debian.tar.xz 907c9e381fd8efb21bd811c1256741b2d02eb04d 6061 golang-github-fhs-go-netrc_1.0.0-3_amd64.buildinfo Checksums-Sha256: d066458507c4f0b053a6103fdb9b1df40325b90aeeb1dd62974eb5aafec4714a 2189 golang-github-fhs-go-netrc_1.0.0-3.dsc a10da2bd1463ed0cdf2a62fffa30c0173b4a86998ef6875b7d19ee7a32e900a2 3288 golang-github-fhs-go-netrc_1.0.0-3.debian.tar.xz c43011418072426137f54d018eb778a5c9c32f379121cfed4f8f97130c54b0c3 6061 golang-github-fhs-go-netrc_1.0.0-3_amd64.buildinfo Files: 632356143a128902fae0c7338a2c7f53 2189 devel optional golang-github-fhs-go-netrc_1.0.0-3.dsc 1e5040f9aa4a66374ff499c0e359f44c 3288 devel optional golang-github-fhs-go-netrc_1.0.0-3.debian.tar.xz 01e6115369934c3014ba46b67701d801 6061 devel optional golang-github-fhs-go-netrc_1.0.0-3_amd64.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEsjhixBXWVlpOhsvXV5wWDUyeI+gFAmAeuaEACgkQV5wWDUye I+gvnA/8CalK6LeOmYSn+2uxROhTW3MiGsFMfbASVW2FvZ/deH4SFzmZ66dAf8hi h5VCO00n23sjCCNGruySoJN+rAfrGQJykIjDw0Q5R/UT+Onq/NR6T1Pn0io5lwR8 OuNXoBU9EMsPRo1kHr7d7T5ftaNS+dfhqiT7bp7aXGjUqoFg2k7/pNSLe9J1iha7 Zi9NGsnTPOjTC+fw76UxIqF7s2/aoshQkZFFynSyHa2s+mc3QxPLHL85/Dq/x3O/ b34tVzei0QaZlmuGMLHyPkevmMYAQMTr4aa3Gt0cuoKv40mPF0/kqeDFYzhj/XJx cINZLHDJerB26GgVxU5oAHetE1rECxpoUCb0ExqRHsYGoE6rgH33lAAgJNdDpQVk 0WOKfU0X6QXP75qPw74nyvSTJ2bqLehUPNXeqvJ1jGS6ABzR44UGf6y22UWFdBKi A1o+yCT4wW7p1G0jW/JhJIuNqMxBF9jYJF0OMisWmasX4EsxM5YQ9kVg0D4hWJAe gkpwuYERJr0FH57YzRwNbblfP8YmnmNWu9Qf8Who97UTvysLwQQnfJWpinN9h7+4 3Z2jwIw/SttExyIFFKJYuekNJu7f1hbl8QUFB7xFdN0nBxBY03zTTLq172fR63jJ mmyo+YLYbu9UKadnpss0tXgwpklqBOoXRbWpdDy+S4nCLRHetSE= =pFKB -END PGP SIGNATURE-
Accepted golang-github-fhs-gompd 2.0.3-1.1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sat, 09 Jan 2021 13:37:13 +0100 Source: golang-github-fhs-gompd Architecture: source Version: 2.0.3-1.1 Distribution: unstable Urgency: medium Maintainer: Debian Go Packaging Team Changed-By: Holger Levsen Changes: golang-github-fhs-gompd (2.0.3-1.1) unstable; urgency=medium . * Non maintainer upload by the Reproducible Builds team. * No source change upload to rebuild on buildd with .buildinfo files. Checksums-Sha1: c88b922b7f2d2ab8d03d33b694fba45b78224cad 2164 golang-github-fhs-gompd_2.0.3-1.1.dsc 9d14062ea08d22a414ce9a85a2f8cfeaf910f4e9 1952 golang-github-fhs-gompd_2.0.3-1.1.debian.tar.xz afdbb51156bb2e8e7e6c0cc5352aef7af314ce3a 5843 golang-github-fhs-gompd_2.0.3-1.1_source.buildinfo Checksums-Sha256: cd10eb6e54cfa35fe514fcf1a40004986b169b31950d93bfc481277c9571eaff 2164 golang-github-fhs-gompd_2.0.3-1.1.dsc ecc593c970c4687a2b2942946d90a8876729f77a28e2c8a9e7409d3dac055081 1952 golang-github-fhs-gompd_2.0.3-1.1.debian.tar.xz 5daeb8dcf92ed01c3ef8e46e625125bd704952a77611e1cd2ff1a91ac98cdeca 5843 golang-github-fhs-gompd_2.0.3-1.1_source.buildinfo Files: 29f0425f59e434f9cc1747b1a02996a8 2164 devel optional golang-github-fhs-gompd_2.0.3-1.1.dsc a101249ece79feae4521f018438c8c43 1952 devel optional golang-github-fhs-gompd_2.0.3-1.1.debian.tar.xz d60a36ef2034953e7a13ad3cde01ff7a 5843 devel optional golang-github-fhs-gompd_2.0.3-1.1_source.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEuL9UE3sJ01zwJv6dCRq4VgaaqhwFAl/5o/kACgkQCRq4Vgaa qhxSQw//cTnonINahjTo+6ddjhyX7JJYAQ0T2RkfYu70nLhkqjpIeum+11ymi/Cy B5We7Y/LnYGJBXTHQMagklaUJ4XqCSF+P6WZlWAcvP8pOqBX/eAmx2izCfvGjhiB oCJ4OzY6eM2XtHUzBKPZ5g+UDPCODAMUwX3uVBr7wEm2eJcpsY+A4igZCL8kNTt6 GERIn5kbsj/wa3CVhWVuqPCPUvcfrzVO/Ly/b9Q5952oM5H9iAxKc9VtmJh8WL0F 9TLe6ecysvgIcOZny8PIxJmax23k0rRgNMT3GTmC7MXx+zBcNrOCFYL1d02XNyoC V+MfK05loW0rmWk0vD9xBoEDvXl2vL9ONEiO+qXQdyXr/Q3r44NB5fUbR7Iyl7Lu kc5lyVKtTVct9BuHs9BW41awDMD8CixwRQP/UnOV664tpd9Nq9rz/eKajMq8tGY7 ms4Z/ynYRPxa/Nuumy+ZXQXnj3E9F2SsvfWSFxCA7EuaNIUhVY01Z6xDufk6UA00 52XyIqUofCNXS7talQ+aCJ6tJRVOQurf8SzRdgDsHoMyAqXp90IX9mSgHFD3Nnkn qTNnrr1dLRxsGkI/DLZ2g07zIkVONbwMn3IGZyODUinGpmMlRGlNqXsZoVtUyxJ5 p83q5UGKvbyhXNCelHsZInNT5bDcy+uB4UnW+Qj/s0+pRSKfhZk= =2ze1 -END PGP SIGNATURE-
Accepted golang-github-fhs-go-netrc 1.0.0-2 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Tue, 12 Feb 2019 23:49:15 +0100 Source: golang-github-fhs-go-netrc Architecture: source Version: 1.0.0-2 Distribution: unstable Urgency: low Maintainer: Debian Go Packaging Team Changed-By: Nicolas Braud-Santoni Changes: golang-github-fhs-go-netrc (1.0.0-2) unstable; urgency=low . [ Alexandre Viau ] * Point Vcs-* urls to salsa.debian.org. . [ Nicolas Braud-Santoni ] * Switch to debhelper 12. Compatibility level now controlled by a Build-Depends * debian/control + Updating uploader's email address + Declare compliance with policy v4.3.0. No change required * debian/gbp.conf: Re-enable pristine-tar Checksums-Sha1: e6bfba1268b3bf1996c504c99bd8ee1f42997096 2189 golang-github-fhs-go-netrc_1.0.0-2.dsc 68524e17f109321226fad16169b6ee6cc9fc7eaa 3092 golang-github-fhs-go-netrc_1.0.0-2.debian.tar.xz 59a35002a5f46a08933a9bbd2cd23898c227ba1e 5575 golang-github-fhs-go-netrc_1.0.0-2_amd64.buildinfo Checksums-Sha256: 1fcaa8d964e4dae08d05f2027ccf9e3d1cab8aab7ffe1565fb0955d3191f53e4 2189 golang-github-fhs-go-netrc_1.0.0-2.dsc 4b65463621d9d164b04c35ae0a4cd74c49044fe72b4842523b6938b40676ec4a 3092 golang-github-fhs-go-netrc_1.0.0-2.debian.tar.xz 86af97e031f323cd598168f050a4da9698f9be05873727d62c5dace64155b233 5575 golang-github-fhs-go-netrc_1.0.0-2_amd64.buildinfo Files: 52b22b355f0d8de90a4bfc77d1eba530 2189 devel optional golang-github-fhs-go-netrc_1.0.0-2.dsc 5743b64d3753a4d5f8dbe3a35e0bc7b0 3092 devel optional golang-github-fhs-go-netrc_1.0.0-2.debian.tar.xz d54c7abb34566a839532bf2d648bb8c6 5575 devel optional golang-github-fhs-go-netrc_1.0.0-2_amd64.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEU7EqA8ZVHYoLJhPE5vmO4pLV7MsFAlxjTd0ACgkQ5vmO4pLV 7MtFYg/9FUxP83p1rP1Q0Ge9O8gzzXJOH8qsR9H7lfgwRJTlUisa4rlwZIlCyTOw liN+OZWX402zDyqgLxlaKPAzD6hdQi9uXXld1d2cAFzAXxdyKas4i5NAkqlyWo7O +r7h/nWXxeWUq1tsin/hLHlNvkDHdLYT3nJw2byNgAPCUP/GIdmFGxOzJG9m9ZDE NilC3H/fS8GMkLdWwwe2tKGuqgeHRKcSWFG6eJ72utpv5VAdxwW0agPejQwcosjF MMLuHSu4ZRjXPbsb9ncLPWpBcehdu8SpmxvoLKGgh57b+JDySP9xsJhHBnxIR9Xu HnQfWvexlBxS6qEYtGjx+eYxSkxwNEmcgGLJv/mkZsppIcBsC/p4E11XmqVdzNMI zX/ZMXjBYP1q3i/NOT3ts3XuxbwWAKr8gtu6oR/yBh+Sxjlp9FMBgz/7lQXue83i uzhslizgc3sXl4yc1gr+kkLAw+uWGmn9pBExZ07xLEYHVYAvZb1C/R6bW/Hnkz40 X0nykwSgDEAZ+nVEQFSRCiQvkRu1nWJ4VACoqyLPFNapxk6ZRKYBUeM1QzVUPqys RpD4ze8wCTDAQXKGwEdxtm+04fNdbCXFtTfKwJxhhgLV2B3eBrZ/xOZnqVMx2EMC zNXV2x5XmHbRLJrzRPbYi7Q9Cs1xJKzV+QikJXX/qnWfzjm9cGs= =xrVw -END PGP SIGNATURE-
Accepted golang-github-fhs-gompd 2.0.3-1 (source all) into unstable, unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Fri, 01 Feb 2019 22:49:24 -0500 Source: golang-github-fhs-gompd Binary: golang-github-fhs-gompd-dev Architecture: source all Version: 2.0.3-1 Distribution: unstable Urgency: medium Maintainer: Debian Go Packaging Team Changed-By: Clint Adams Description: golang-github-fhs-gompd-dev - MPD client library Changes: golang-github-fhs-gompd (2.0.3-1) unstable; urgency=medium . * Initial release. Checksums-Sha1: 187b46f1f8de04df2b123fd97ecc55decb977de5 2156 golang-github-fhs-gompd_2.0.3-1.dsc 06be568c4fa820e8bea7c3bc6df32fb37458e4bb 17444 golang-github-fhs-gompd_2.0.3.orig.tar.xz fe2e97dfc18b38023915f7581244e4241126fb69 1836 golang-github-fhs-gompd_2.0.3-1.debian.tar.xz 5053b78985c2bb14bbc00301e7f71d3bac716ddc 17668 golang-github-fhs-gompd-dev_2.0.3-1_all.deb 65fbc645a1b22eb81b37f97001d54fc898332fdb 5517 golang-github-fhs-gompd_2.0.3-1_amd64.buildinfo Checksums-Sha256: 95ba1f36a8d79cd11920e5ca8d4b4e1c6885afccf2acd8cde0463d9f9b72ca8a 2156 golang-github-fhs-gompd_2.0.3-1.dsc b75483162239a629bd5b19e55d880a3ca9a38be2541d26cc76c02c86593dfc5a 17444 golang-github-fhs-gompd_2.0.3.orig.tar.xz 2e8ba2cd9a3fd328fb119a989f7c7f80abed77735c6fa72aa8429b0586e04b26 1836 golang-github-fhs-gompd_2.0.3-1.debian.tar.xz 029f7da2a6505cc500e08bcb9790c3bd95b9cbf8dd44c4b32953b6f0378b9e6f 17668 golang-github-fhs-gompd-dev_2.0.3-1_all.deb f4914104411b923c5cf79fb8159a1440278109593ae320d4ea3fa4c106aecdc0 5517 golang-github-fhs-gompd_2.0.3-1_amd64.buildinfo Files: a7d2178363e43ec781cb63a08d9ababd 2156 devel optional golang-github-fhs-gompd_2.0.3-1.dsc 31d45dc80bbc9784c17b77db4ae3f401 17444 devel optional golang-github-fhs-gompd_2.0.3.orig.tar.xz 9089ec111dd976e177cd1fdd16862f36 1836 devel optional golang-github-fhs-gompd_2.0.3-1.debian.tar.xz e1b8d5f39f83038dcfd8d67ac3b9be67 17668 devel optional golang-github-fhs-gompd-dev_2.0.3-1_all.deb 5067810266954ff3fdd38d5a6d8b36e3 5517 devel optional golang-github-fhs-gompd_2.0.3-1_amd64.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEdYHsh0BT5sgHeRubVZIzHhmdOKgFAlxVFMIACgkQVZIzHhmd OKjXmw//aI0tBDAQcYILMtjPtnrj9hrq4A/3Xgr0bgmvnmVyhRMbATlh4HETJpQ3 +VH+nxmYNbplVORN1MoYcYYbjIPGa9t8zafFlcOl6/dMR6NRK1rHwzH5ji3WoUv/ G0+UfB1vPpco7KAyG6oaC1B3TeRDBfveopU2n7kWoWQZlZinUduHD604ltMhbfw5 UGw6q5mqqaL7MEPaqWsp+RAWZH21SgaGuNY6SUGpESOwdSJhio8AWumHWuG99mAp YEcoV5qtiaVajQ1GcYATR16k/V7reuvqKZnEfdCV28s0IwXsfCuZ7F1QLuRIA6tu p9PCZPeclgJlKWxODI3LGXRuey4b7zihG/qUtLuwMkp60K0AWfqbYtM5/g11nIRk HzvfiBI09I2QZwgATKXxEV6ZNm31WqOe73BKOSzG/CWwHwdTLuthreKSaT7ORsy6 G3U5153/ymNbMSAcGG6ik7J7cPWRHuzoALGifadtdPlGo4pzwhqN/cCcKEs3RVef 6yNb7WOhrxbZdiL1d/EjgwRDtrvvlezZXLyrNqFEAfUZ/fzJFgjOcY16Aa7+IieX HEX9LBPDJoDEiqqaojJZTaXwHqwbL1QRxUZFXM+1egn66yatr5ct7X8RUEQX77O0 xycybQnM+iA5sor5zGnXwUAV0eTGUhGdCLhlgCFPu//Q1zC2+z0= =ETxW -END PGP SIGNATURE-
Re: FHS: Where to store user specific plugins / code
Hi Jonas, On 18-03-09 19:18:50, Jonas Meurer wrote: > Am 09.03.2018 um 14:23 schrieb Georg Faerber: > >> Ian's comments are good for admin-installed plugins that the users can > >> use. In fact there is good precedent for an app checking > >> /usr/lib/pkg/... for plugins installed from Debian packages, > >> /usr/local/lib/pkg/... for plugins installed by the admin from > >> non-Debian locations, and then finally the user's .config/pkg/... > >> directory. > > > > I guess we'll go with /usr/local/lib/schleuder then? Does this sound > > like a reasonable choice? > > I don't think it's allowed for Debian packages to create subdirectories > under /usr/local, is it? According to the policy, that's allowed [1]: "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. These are not directories in /usr/local, but are children of directories in /usr/local. These directories (/usr/local/*/dir/) should be removed on package removal if they are empty. Note that this applies only to directories below /usr/local, not in /usr/local. Packages must not create sub-directories in the directory /usr/local itself, except those listed in FHS, section 4.5. However, you may create directories below them as you wish. You must not remove any of the directories listed in 4.5, even if you created them." Cheers, Georg [1] https://www.debian.org/doc/debian-policy/#site-specific-programs signature.asc Description: Digital signature
Re: FHS: Where to store user specific plugins / code
On 09.03.2018 14:23, Georg Faerber wrote: Hi, > I guess we'll go with /usr/local/lib/schleuder then? Does this sound> like a reasonable choice? That would be my choice. OTOH, it might be nice to have a helper that automatically creates deb packages. (would also be nice for other applications, eg. moz). --mtx -- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering i...@metux.net -- +49-151-27565287
Re: FHS: Where to store user specific plugins / code
Am 09.03.2018 um 14:23 schrieb Georg Faerber: >> Ian's comments are good for admin-installed plugins that the users can >> use. In fact there is good precedent for an app checking >> /usr/lib/pkg/... for plugins installed from Debian packages, >> /usr/local/lib/pkg/... for plugins installed by the admin from >> non-Debian locations, and then finally the user's .config/pkg/... >> directory. > > I guess we'll go with /usr/local/lib/schleuder then? Does this sound > like a reasonable choice? I don't think it's allowed for Debian packages to create subdirectories under /usr/local, is it? You could still read in plugins from this path in case it exists and document that users ... aehm, admins ... shall create it and put their plugins there. Cheers jonas signature.asc Description: OpenPGP digital signature
Re: FHS: Where to store user specific plugins / code
Hi, On 18-02-28 18:14:17, Marvin Renich wrote: > If a user get to install his/her own plugins, they should go in the > user's home directory, e.g. /home/user/.config/scheduler/plugins/. > Non-root users should not generally be given write permission to > /usr/local, and definitely not to /usr/lib. See my separate mail: The term "user" used by me was misleading, I guess, more appropriate would have been "admin". > If the app takes care of installing the plugins on the user's behalf, > that is slightly different. However, if the plugin can be selected by > the user from a non-trusted source, I would still go with the user's > directory. Allowing a non-root user to put his own plugin where > others can execute it without being able (even required) to verify its > integrity is a huge security hole. The app doesn't take care of installing the plugins. This would be the job of the admin, using whichever technique they're comfortable with. > Ian's comments are good for admin-installed plugins that the users can > use. In fact there is good precedent for an app checking > /usr/lib/pkg/... for plugins installed from Debian packages, > /usr/local/lib/pkg/... for plugins installed by the admin from > non-Debian locations, and then finally the user's .config/pkg/... > directory. I guess we'll go with /usr/local/lib/schleuder then? Does this sound like a reasonable choice? Thanks, Georg signature.asc Description: Digital signature
Re: FHS: Where to store user specific plugins / code
Hi, On 18-03-01 07:55:08, Peter Silva wrote: > -- it is best practice for daemons/services not to run as root. They > should have an application specific user. Schleuder does use a dedicated user, called schleuder. $HOME is set to /var/lib/schleuder. Inside there mailing list specific data is stored. Cheers, Georg signature.asc Description: Digital signature
Re: FHS: Where to store user specific plugins / code
Hi all, Thanks for your replies, and sorry for the delay in answering. (Note to myself: Don't write such mails while traveling..) That said, I think I wasn't clear regarding "user specific": On 18-02-28 18:54:14, Georg Faerber wrote: > Currently, we allow users to run / execute their own plugins, stored > in /etc/schleuder/plugins. Obviously, that's not the right place, as > /etc is for config files, not executable code. We would like to fix > this, but are unsure which location to offer. The (empty) directory > would be provided by the package, but the (possible) content would be > provided by the user. > > Therefore, I'm wondering what's the correct place: Would > /usr/local/lib/schleuder/plugins be sensible? If not, any other place > which is more suitable? Using "user" I meant not the real "end-users", sending mail, but the "user" (an admin running a mailserver) who installs schleuder. Cheers, Georg signature.asc Description: Digital signature
Re: FHS: Where to store user specific plugins / code
On Wed, 2018-02-28 at 18:14:17 -0500, Marvin Renich wrote:
> * Ian Jackson <ijack...@chiark.greenend.org.uk> [180228 17:45]:
> > Georg Faerber writes ("FHS: Where to store user specific plugins / code"):
> > > Currently, we allow users to run / execute their own plugins, stored in
> > > /etc/schleuder/plugins. Obviously, that's not the right place, as /etc
> > > is for config files, not executable code. We would like to fix this, but
> > > are unsure which location to offer. The (empty) directory would be
> > > provided by the package, but the (possible) content would be provided by
> > > the user.
> > >
> > > Therefore, I'm wondering what's the correct place: Would
> > > /usr/local/lib/schleuder/plugins be sensible? If not, any other place
> > > which is more suitable?
> > Do plugins do something which people might not want if present, and
> > not configured ? If so then perhaps you want a thing a bit like the
> > apache mods-enabled scheme: a link farm.
> >
> > If not, then if it's easy to do I would load all plugins in
> > /usr/local/lib/schleuder/plugins
> > /usr/lib/schleuder/plugins
> > (former masking the latter with for with the same name)
>
> If a user get to install his/her own plugins, they should go in the
> user's home directory, e.g. /home/user/.config/scheduler/plugins/.
Definitely not under .config, for the same reasons it would be wrong
for those to go under /etc.
From the XDG Base Dir spec, the thing that's somewhat closest is
$XDG_DATA_HOME with a default of $HOME/.local/share. But that spec is
lacking in many places, and a missing .local/bin and .local/lib are
among those.
There are the logical extensions for those at
<https://theos.kyriasis.com/~kyrias/basedir-spec.html>, but
unfortunately nothing seems to refer to XDG_LIB_HOME on sources.d.o. :(
Thanks,
Guillem
Re: FHS: Where to store user specific plugins / code
another option:
-- it is best practice for daemons/services not to run as root. They
should have an application specific user.
-- some tools can be run in a systemish way by a specific user, but
also by other users in a less official way (think web server on a high
port instead of port 80.)
-- user preferences are standardized by freedesktop.org
https://specifications.freedesktop.org/basedir-spec/latest/ar01s03.html
So preferences/plugin settings would go under ~/.config/package/ for
whatever user is running the tool.
state files under ~/.cache/package/ The systemd.service file will
have User=, so the "normal"
service settings will be under ~.
It seems much cleaner to me than the httpd link farms, and allows
users to spin up their own daemons
(user httpd on a high port) with a natural location for settings.
This aligns with systemd where they have the --user flag to let users
manage their own daemons.
On Thu, Mar 1, 2018 at 7:26 AM, Ian Jackson
<ijack...@chiark.greenend.org.uk> wrote:
> Marvin Renich writes ("Re: FHS: Where to store user specific plugins / code"):
>> [stuff]
>
> I agree completely with Marvin's message.
>
> Ian.
>
Re: FHS: Where to store user specific plugins / code
Marvin Renich writes ("Re: FHS: Where to store user specific plugins / code"):
> [stuff]
I agree completely with Marvin's message.
Ian.
Re: FHS: Where to store user specific plugins / code
On Wed, 28 Feb 2018 09:54:14 -0800 Georg Faerber ge...@riseup.net wrote Therefore, I'm wondering what's the correct place: Would /usr/local/lib/schleuder/plugins be sensible? If not, any other place which is more suitable? If they're binaries, the FHS answer is that they go in /usr/libexec, but I don't think Debian even has that anymore. /usr/lib/schleuder/$PLATFORM would be consistent with a lot of other packages (e.g. gcc); FHS says each application can get 1 folder in /usr/lib and can put platform-specific folders under that. I'd shy away from doing anything at all to /usr/local, since there's an implicit (or even explicit?) promise that dpkg won't ever touch that. WMG
Re: FHS: Where to store user specific plugins / code
* Ian Jackson <ijack...@chiark.greenend.org.uk> [180228 17:45]:
> Georg Faerber writes ("FHS: Where to store user specific plugins / code"):
> > I'm maintaining schleuder in Debian [1], a "gpg-enabled mailing list
> > manager with resending-capabilities".
> >
> > Currently, we allow users to run / execute their own plugins, stored in
> > /etc/schleuder/plugins. Obviously, that's not the right place, as /etc
> > is for config files, not executable code. We would like to fix this, but
> > are unsure which location to offer. The (empty) directory would be
> > provided by the package, but the (possible) content would be provided by
> > the user.
> >
> > Therefore, I'm wondering what's the correct place: Would
> > /usr/local/lib/schleuder/plugins be sensible? If not, any other place
> > which is more suitable?
>
> Do plugins do something which people might not want if present, and
> not configured ? If so then perhaps you want a thing a bit like the
> apache mods-enabled scheme: a link farm.
>
> If not, then if it's easy to do I would load all plugins in
> /usr/local/lib/schleuder/plugins
> /usr/lib/schleuder/plugins
> (former masking the latter with for with the same name)
If a user get to install his/her own plugins, they should go in the
user's home directory, e.g. /home/user/.config/scheduler/plugins/.
Non-root users should not generally be given write permission to
/usr/local, and definitely not to /usr/lib.
If the app takes care of installing the plugins on the user's behalf,
that is slightly different. However, if the plugin can be selected by
the user from a non-trusted source, I would still go with the user's
directory. Allowing a non-root user to put his own plugin where others
can execute it without being able (even required) to verify its
integrity is a huge security hole.
Ian's comments are good for admin-installed plugins that the users can
use. In fact there is good precedent for an app checking
/usr/lib/pkg/... for plugins installed from Debian packages,
/usr/local/lib/pkg/... for plugins installed by the admin from
non-Debian locations, and then finally the user's .config/pkg/...
directory.
...Marvin
Re: FHS: Where to store user specific plugins / code
Georg Faerber writes ("FHS: Where to store user specific plugins / code"):
> I'm maintaining schleuder in Debian [1], a "gpg-enabled mailing list
> manager with resending-capabilities".
>
> Currently, we allow users to run / execute their own plugins, stored in
> /etc/schleuder/plugins. Obviously, that's not the right place, as /etc
> is for config files, not executable code. We would like to fix this, but
> are unsure which location to offer. The (empty) directory would be
> provided by the package, but the (possible) content would be provided by
> the user.
>
> Therefore, I'm wondering what's the correct place: Would
> /usr/local/lib/schleuder/plugins be sensible? If not, any other place
> which is more suitable?
Do plugins do something which people might not want if present, and
not configured ? If so then perhaps you want a thing a bit like the
apache mods-enabled scheme: a link farm.
If not, then if it's easy to do I would load all plugins in
/usr/local/lib/schleuder/plugins
/usr/lib/schleuder/plugins
(former masking the latter with for with the same name)
Ian.
FHS: Where to store user specific plugins / code
Hi Debian Developers, all, I'm maintaining schleuder in Debian [1], a "gpg-enabled mailing list manager with resending-capabilities". Currently, we allow users to run / execute their own plugins, stored in /etc/schleuder/plugins. Obviously, that's not the right place, as /etc is for config files, not executable code. We would like to fix this, but are unsure which location to offer. The (empty) directory would be provided by the package, but the (possible) content would be provided by the user. Therefore, I'm wondering what's the correct place: Would /usr/local/lib/schleuder/plugins be sensible? If not, any other place which is more suitable? Looking forward to your input! All the best, cheers, Georg [1] https://tracker.debian.org/pkg/schleuder signature.asc Description: Digital signature
Accepted golang-github-fhs-go-netrc 1.0.0-1 (source all) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Tue, 16 Jan 2018 14:36:02 +0100 Source: golang-github-fhs-go-netrc Binary: golang-github-fhs-go-netrc-dev Architecture: source all Version: 1.0.0-1 Distribution: unstable Urgency: medium Maintainer: Debian Go Packaging Team <pkg-go-maintain...@lists.alioth.debian.org> Changed-By: Nicolas Braud-Santoni <nico...@braud-santoni.eu> Description: golang-github-fhs-go-netrc-dev - netrc file parser for Go programming language Changes: golang-github-fhs-go-netrc (1.0.0-1) unstable; urgency=medium . * New upstream release Identical to the previously-packaged git commit * Update debian/gbp.conf * debian/control: Bump Standards-Version to 4.1.3 Replace `Priority: extra` with `optional` * Switch to debhelper 10 Checksums-Sha1: 5a4d1ed28fddf236005682890de5587106b28608 2227 golang-github-fhs-go-netrc_1.0.0-1.dsc 66b8a42dd57b1f396f05712cc52318b74a81a312 3537 golang-github-fhs-go-netrc_1.0.0.orig.tar.gz b3b8eaccd983714be9be253fad8c7423693529f5 2412 golang-github-fhs-go-netrc_1.0.0-1.debian.tar.xz ed071b762ac4a1e2d6a5a1988d9c6f945554938b 5104 golang-github-fhs-go-netrc-dev_1.0.0-1_all.deb 697c393ebb3b9528e810a9fdc2838380f7f8d0b1 5560 golang-github-fhs-go-netrc_1.0.0-1_amd64.buildinfo Checksums-Sha256: 8e53732d54c2656eab4dc8c86a9b6a93a38c1c2b20ac79307981b429912d8bf2 2227 golang-github-fhs-go-netrc_1.0.0-1.dsc b434a489a7bbab16f2d801eb08f4058f3feefda4c8127754d87a85d35e39b62c 3537 golang-github-fhs-go-netrc_1.0.0.orig.tar.gz d24157580a5801cd7cde60de0ef46465a127c504764c1808c9045e4c91ac5616 2412 golang-github-fhs-go-netrc_1.0.0-1.debian.tar.xz ecf055e8a4dcad057a6bb297aab7e9888964ff26f0d3fdc4861645dcdba7f6f9 5104 golang-github-fhs-go-netrc-dev_1.0.0-1_all.deb 7ffd9165ef34b548a984d6c0b903d006293a869024c8b62257662acb1e3717f1 5560 golang-github-fhs-go-netrc_1.0.0-1_amd64.buildinfo Files: 895a8bf783df7e816dd011e499898f7a 2227 devel optional golang-github-fhs-go-netrc_1.0.0-1.dsc c9d01288fd67ed4405f58b7406beb164 3537 devel optional golang-github-fhs-go-netrc_1.0.0.orig.tar.gz 85160bb56780fdef18d4c51914b5de1e 2412 devel optional golang-github-fhs-go-netrc_1.0.0-1.debian.tar.xz e848734b19915b935fef09744c8c54c1 5104 devel optional golang-github-fhs-go-netrc-dev_1.0.0-1_all.deb cf11b77d4e1860fe108612aaf0f76510 5560 devel optional golang-github-fhs-go-netrc_1.0.0-1_amd64.buildinfo -BEGIN PGP SIGNATURE- iQJDBAEBCgAtFiEExyA8CpIGcL+U8AuxsB0acqyNyaEFAlpeAJgPHGpjY0BkZWJp YW4ub3JnAAoJELAdGnKsjcmhzVYP+gOKic/8R3iT9Cmi5GLvy1Pv0EqjLw0o7c9t 5Oy0C9AfyJagTu3TNiKa0YYO2HDj9ZQybIn3D8DmPWe0Aqv4s3IOdR187Bmtm2bs 6xTHB0n1wRkcQ028bpXRHBvnnOfe18m2GMxKYj2guZ53LFE4e7FMXIMctVP8axlw J9RVfW4oPnHiyDzZOERmsw4stoJPi3DY7GPdJREfHZKb6919VdhD3uwkPpQrqZfs koGKvPbei7y+yBm37CQRBeG4Y3qOiG+wbST5qhwHohTp/rqJmbzprtq2XgVrZv6u TqEGYfbqyKkiH/YGjJMVC+eeUE+1r1HuAy6ccObwdsw94i8S/Y7UO+3uXvm5Q/LN 4PkyMyAFnhqkl6OwGBMGjj1Ia04awAd4W5dskdQwYm1C1F4bomnCiL9G0uXWg2uw 3m73wpAzylxkLIMhYvavdBLQcwgHa9gqq8wk+XcoveRPWw/nt6886qzI+MyqyAdJ 0Sqf+o03fFhC2GRy12fF/ZRS+ncpmvu2vxIRVTNzadQKkQ3dVLrQV2m8pR0hcEZp abBw7h7L+0I3HUH8ClUpMqSUD1z+jmo7T0ykoSAdGNuijyhv76ZTub9w6oT8/uk1 1Bw646PkuQurR3HkeDZkI29T/EKrrWOXbJ3dbtpeysJrXybxM3hE0n5zzpTRc76x Fkg1Q2/S =B/rv -END PGP SIGNATURE-
Bug#823565: ITP: golang-github-fhs-go-netrc -- netrc file parser for Go programming language.
Package: wnpp Severity: wishlist Owner: Nicolas Braud-Santoni <nico...@braud-santoni.eu> * Package name: golang-github-fhs-go-netrc Version : 0.0~git20160504.0.4ffed54-1 Upstream Author : Fazlul Shahriar * URL : https://github.com/fhs/go-netrc * License : MIT Programming Lang: Go Description : netrc file parser for Go programming language. This is a dependency of golang-github-octokit-go-octokit
Re: Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
On Thu, Dec 15, 2011 at 12:46:40PM +, Roger Leigh wrote: Speed. [...] encrypted. But this actually does _not_ slow things down: the Linux disk cache is sensibly caching the decrypted data, so often-used stuff from /bin and /lib happily remains in already-decrypted cache. The interesting stuff from /usr is generally too large and too seldomly used to remain cached. This was brought up last time this came up on -devel. And I think it kind of misses the point. You are encrypting / and not encrypting /usr. That's fine. But it's a workaround. It's not addressing the *real* goal, which is to encrypt /etc. That is to say, /usr is a split of /convenience/. The real solution would be to have /etc as a separately-mounted encrypted filesystem. So really, keeping /usr separate is a different issue, IMHO. This isn't a reason to keep the /usr split, it's a reason to support mounting an encrypted /etc in the initramfs. Such a solution would also satisfy those that want a read-only root but writable /etc for admin convenience. This is just not true. If you care about encrypting /etc, you frequently also care about the integrity of /sbin/init so that an attacker can't compromise the whole system, /bin/login and /lib/security so they can't intercept passwords, and so forth. Encrypting the root filesystem provides this integrity checking; while encryption per se is not required, there aren't really any usable signing-only methods at present for authenticating the root filesystem, so if you want to protect against your rootfs having been hijacked, making sure it's encrypted seems to be the way to do it at present. (This assumes that you have signature checking on your initramfs of course, which is a pain in its own right, or that you keep your initramfs on removable media that remains under your control even when the laptop is out of sight; and that if you have /usr as a separate, unencrypted partition, that you do some kind of signature checking on that - perhaps via debsums.) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
Guillem Jover guil...@debian.org writes: Hi! On Thu, 2011-12-15 at 13:43:19 -0400, Joey Hess wrote: Roger Leigh wrote: I think an important point to consider is that /usr would not disappear. It could be replaced by a symlink for new installs. This would permit older installs to continue to use /usr, but the files would end up on / for new installs. So no changes to --prefix would be needed, and the Debian packages themselves could still provide files in /usr. Didn't the hurd port try this several years ago? My impression was that they didn't feel it had been worth the pain, perhaps it's not so easy. The old default was changed for GNU/Hurd not because the setup in itself was considered particularly painful, more because doing so for a single port w/o getting the distribution at large to agree this was something worth supporting was painful as overwrite problems were continuously introduced. regards, guillem Plus you can not ship /usr as symlink in one package and as directory in others. That triggers a file overwrite error during update (for the package containing the symlink). We had this problem with packages shipping files in /lib64 or /usr/lib64 in the past several times. So if /usr is a symlink then everyone has to change to --prefix=/. That is what makes linking /bin and /sbin to /usr/* easier. Less packages to change. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87y5u47tyl.fsf@frosties.localnet
Re: Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
Hi! On Thu, 2011-12-15 at 13:43:19 -0400, Joey Hess wrote: Roger Leigh wrote: I think an important point to consider is that /usr would not disappear. It could be replaced by a symlink for new installs. This would permit older installs to continue to use /usr, but the files would end up on / for new installs. So no changes to --prefix would be needed, and the Debian packages themselves could still provide files in /usr. Didn't the hurd port try this several years ago? My impression was that they didn't feel it had been worth the pain, perhaps it's not so easy. The old default was changed for GNU/Hurd not because the setup in itself was considered particularly painful, more because doing so for a single port w/o getting the distribution at large to agree this was something worth supporting was painful as overwrite problems were continuously introduced. regards, guillem -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111222030044.gc31...@gaara.hadrons.org
Re: Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
On Tue, 20 Dec 2011, Roger Leigh wrote: On Tue, Dec 20, 2011 at 12:11:39AM +0100, J.A. Bezemer wrote: On Mon, 19 Dec 2011, Roger Leigh wrote: [..] Regarding the objections above, which are primarily concerned with the creation of a non-generic initramfs, how does this alternative suggestion sound: - The addition of usr= options analogous to the root= options which permit the bootloader to specify the /usr filesystem to mount. By default would do nothing, but grub could be updated to generate such options on systems with a separate /usr. Nonsense, should come from /etc/fstab. Of course. In case it wasn't implicit from the above, this information would necessarily need to be taken from /etc/fstab by update-grub or its equivalent for other bootloaders when generating grub.cfg (or its equivalent). Apologies for not being clear enough: there should not be a usr= parameter at all. Not in grub.cfg, and not anywhere else. The initramfs itself can (i.e. should) easily read it directly from /etc/fstab. (As I remember seeing elsewhere in this discussion: you could define a mount option mount-in-initramfs in /etc/fstab that the initramfs should look for to find out which filesystems it has to fsck mount.) Best regards, Anne Bezemer -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.lnx.4.64.1112201247070.18...@wormhole.robuust.nl
Re: Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
On Tue, Dec 20, 2011 at 01:17:41PM +0100, J.A. Bezemer wrote: On Tue, 20 Dec 2011, Roger Leigh wrote: On Tue, Dec 20, 2011 at 12:11:39AM +0100, J.A. Bezemer wrote: On Mon, 19 Dec 2011, Roger Leigh wrote: [..] Regarding the objections above, which are primarily concerned with the creation of a non-generic initramfs, how does this alternative suggestion sound: - The addition of usr= options analogous to the root= options which permit the bootloader to specify the /usr filesystem to mount. By default would do nothing, but grub could be updated to generate such options on systems with a separate /usr. Nonsense, should come from /etc/fstab. Of course. In case it wasn't implicit from the above, this information would necessarily need to be taken from /etc/fstab by update-grub or its equivalent for other bootloaders when generating grub.cfg (or its equivalent). Apologies for not being clear enough: there should not be a usr= parameter at all. Not in grub.cfg, and not anywhere else. The initramfs itself can (i.e. should) easily read it directly from /etc/fstab. OK, that does make sense. And it can remain entirely generic, without requiring any special bootloader support. /etc would be the exception to this, so I guess you would be happy with that being made into a separate option? This would be a rare choice, so just patching update-grub should be sufficient. Anyone else who wished to avail themselves of it could just edit the kernel command-line. (As I remember seeing elsewhere in this discussion: you could define a mount option mount-in-initramfs in /etc/fstab that the initramfs should look for to find out which filesystems it has to fsck mount.) This is still a possibility. I discussed an initramfs option for /etc/fstab, but upstream would perfer us to use comment=initramfs or the new free-form x- options e.g. x-initramfs. Like /usr, this could be mounted after the rootfs, with the exception of /etc, as mentioned above. WRT fsck, I think we would continue to mount r/o prior to fsck, as for the rootfs, and then remount r/w afterward in checkroot. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111220165603.gg5...@codelibre.net
Re: Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
On Sun, Dec 18, 2011 at 03:37:43AM +0100, Marco d'Itri wrote: On Dec 17, Roger Leigh rle...@codelibre.net wrote: So WRT mounting /usr (and potentially /etc and other filesystems), I've pushed patches upstream for util-linux (initramfs mount option) and initramfs-tools (generate /etc/fstab from host and mount after rootfs). (Merging this and the reply to #652459) I'd just like to clear up a few points about the desired behaviour and requirements for the initramfs. I have some ideas about other ways to achieve this goal. 1) Generation of /etc/fstab in the initramfs, including the rootfs and all the filesystems desired to be mounted This is highly suboptimal, because it suddenly makes the initramfs not generic anymore. The initramfs should: - mount / as usual - look at the rootfs fstab - mount /usr using the information from the rootfs fstab Regarding keeping the initramfs generic, we already permit hardcoding of the rootfs into the image. This is overridden by root=xxx, but still permitted. I'm not sure I see the difference between hardcoding the root device rather than an fstab entry. There is of course the addition of the mount options, which might be incompatible if the fstype of the rootfs changes. 2) In local mountroot(), rather than just mounting the rootfs, loop over all mountpoints in /etc/fstab and mount them. If there is no need to mount file systems other than /usr, why do it? It would permit additional flexibility for initramfs extensions by users. I'm not sure if this is necessarily a good or bad thing. If it's desirable not to permit this, I'm sure we can find a better way. Mounting /usr is obviously the main goal here. Whether or not we migrate stuff to or from /usr, we would still need to have the ability to mount /usr in the initramfs for compatibility with systems with a separately-mounted /usr, in order to privide the guarantee that /usr is available in early boot. Mounting /etc separately is not essential, but this would be a nice-to- have feature for those who wish to encrypt it. and other files to the root filesystem. It additionally permits mounting of /etc separately, thereby permitting it to be encrypted and/or writable while the root filesystem is unencrypted and/or read-only. I do not believe that this is desireable, it is complex and would come for free anyway by a / - /usr move. Why would it come for free? You would still have files in places other than /etc on the rootfs. And if we are deprecating a separate /usr, it doesn't solve the problem at all, since everything would be on the rootfs, and then everything would be encrypted. As mentioned earlier in the thread, encrypting /etc is an entirely different problem than mounting /usr separately--a separate mount would IMO be the best solution to this problem, and mounting it in the initramfs is certainly technically possible. Regarding the objections above, which are primarily concerned with the creation of a non-generic initramfs, how does this alternative suggestion sound: - The addition of usr= options analogous to the root= options which permit the bootloader to specify the /usr filesystem to mount. By default would do nothing, but grub could be updated to generate such options on systems with a separate /usr. - We could also add an additional etc= option with the same semantics. I'll be happy to implement this if this sounds more acceptable than the existing approach. It does, I think, address your primary criticisms. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111219201051.gb5...@codelibre.net
Re: Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
On Mon, 19 Dec 2011, Roger Leigh wrote: [..] Regarding the objections above, which are primarily concerned with the creation of a non-generic initramfs, how does this alternative suggestion sound: - The addition of usr= options analogous to the root= options which permit the bootloader to specify the /usr filesystem to mount. By default would do nothing, but grub could be updated to generate such options on systems with a separate /usr. Nonsense, should come from /etc/fstab. - We could also add an additional etc= option with the same semantics. Something like this would be necessary to support separately mounted /etc, but I see that as a completely separate discussion. Also note that you would need to patch _all_ existing bootloaders for _all_ arches to automatically include that option in any generated config file (namely by parsing the oneonly main config location which is /etc/fstab or possibly /etc/fstab.d). Related issue: how to specify desired fsck options (such as FSCKFIX) for / and /etc, while /etc is not yet mounted. Next, you'll be arguing that /etc/fstab should be moved to /. And /etc/default/rcS too. Oh, and now that I'm at it, do we also have initramfs support for bootlogd? and keyboard-setup? and hwclockfirst? (Last two could be required for proper fsck on various arches.) Plus their config files. Best regards, Anne Bezemer -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.lnx.4.64.1112192352230.14...@wormhole.robuust.nl
Re: Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
On Tue, Dec 20, 2011 at 12:11:39AM +0100, J.A. Bezemer wrote: On Mon, 19 Dec 2011, Roger Leigh wrote: [..] Regarding the objections above, which are primarily concerned with the creation of a non-generic initramfs, how does this alternative suggestion sound: - The addition of usr= options analogous to the root= options which permit the bootloader to specify the /usr filesystem to mount. By default would do nothing, but grub could be updated to generate such options on systems with a separate /usr. Nonsense, should come from /etc/fstab. Of course. In case it wasn't implicit from the above, this information would necessarily need to be taken from /etc/fstab by update-grub or its equivalent for other bootloaders when generating grub.cfg (or its equivalent). They presumably already do the same for / (or look at the current rootfs), so it's simply copying existing practice for the rootfs. - We could also add an additional etc= option with the same semantics. Something like this would be necessary to support separately mounted /etc, but I see that as a completely separate discussion. Also note that you would need to patch _all_ existing bootloaders for _all_ arches to automatically include that option in any generated config file (namely by parsing the oneonly main config location which is /etc/fstab or possibly /etc/fstab.d). Agreed. In order to guarantee that /usr is always available, we will need to support this for all bootloaders. As an aside, this support would only be required for situations where a separate /usr is used /and/ stuff on /usr is required for early boot. Support for minor tools/platforms might not be required since the other solution is simple: keep /usr on the rootfs if you need those guarantees. Either way, having support in the initramfs is a prerequisite for updating the bootloaders. Related issue: how to specify desired fsck options (such as FSCKFIX) for / and /etc, while /etc is not yet mounted. I would presume that this would be unchanged. By the time fsck is run, you'll have / and additionally /etc and/or /usr mounted, so keeping it on /etc will be just fine. Next, you'll be arguing that /etc/fstab should be moved to /. And /etc/default/rcS too. No. I'm simply proposing a way to make additional guarantees about the availability of /usr in early boot. Nothing else is changed except for when /usr is mounted. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111220001514.gd5...@codelibre.net
Re: Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
On Thu, Dec 15, 2011 at 01:29:18PM +, Roger Leigh wrote: WRT mounting additional filesystems in the initramfs, how difficult would it be to add an additional mount option to /etc/fstab entries, e.g. init or initramfs to mark them as being required for mounting in the initramfs. This could include /, /usr, /etc and anything else the admin deems necessary for booting, and would just be checked and added when creating/updating the initramfs. So WRT mounting /usr (and potentially /etc and other filesystems), I've pushed patches upstream for util-linux (initramfs mount option) and initramfs-tools (generate /etc/fstab from host and mount after rootfs). Once fully implemented, this will guarantee the presence of /usr from before init starts, which will solve all the current problems of the / vs. /usr separation. Obviously this is a separate problem to whether /usr should be kept in the long run, but it does make guarantees WRT the availability of files which we currently don't. This would, for example, permit the removal of duplicated files in / and /usr which would make future migration possible. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111217132508.ga23...@codelibre.net
Re: Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
On Dec 17, Roger Leigh rle...@codelibre.net wrote: So WRT mounting /usr (and potentially /etc and other filesystems), I've pushed patches upstream for util-linux (initramfs mount option) and initramfs-tools (generate /etc/fstab from host and mount after rootfs). From my answer to #652459: This is highly suboptimal, because it suddenly makes the initramfs not generic anymore. The initramfs should: - mount / as usual - look at the rootfs fstab - mount /usr using the information from the rootfs fstab -- ciao, Marco signature.asc Description: Digital signature
Re: Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
Russ Allbery r...@debian.org writes: Zachary Harris zacharyhar...@hotmail.com writes: My understanding of the FHS would be that if a library is a dependency of a binary in /bin or /sbin, then such library belongs in /lib, not /usr/lib. (If for some reason the library is also desired in /usr/lib then a sym link from /lib to /usr/lib, but not the other way around, is acceptable.) A review of past bug reports (e.g. #633019 and #639939 from this summer) shows that this policy gets repeatedly violated in Debian until someone catches it. I'm increasingly convinced by the recent discussion on debian-devel that doing all the (rather substantial) work required to keep this separation working is a waste of our collective time. We're not doing a very good job at it anyway, chasing all the library dependencies is a fair amount of work, and things have to keep moving around as dependencies change. And this is all to support use cases that, while real, are fairly marginal in my estimation. This does not seem like the most effective place for us to be spending our time. I don't know if it's worth the effort to unify /bin and /usr/bin or the other similar things that have been discussed from time to time, but I do think it may be time for Debian to just officially say that we don't support /usr on a (meaningfully) separate partition from /bin and /lib, and that binaries in /bin may have dependencies on /usr/lib. Absolutely NO, NO, NO. You can't just break all the systems out there that do have a seperate /usr partition. And that isn't what was suggested. The suggested approach is to have /usr mounted in initramfs (or in one of the first boot scripts). So what Debian could officially say is that /usr will be mounted and packages may freely use it at any time during boot. That the seperation of / and /usr becomes unimportant because both will always be available. But before any of that happens please first show us a working implementation of mounting /usr from initramfs and as first thing during boot. And that should probably be included in a stable release before the seperation of / and /usr is declared meaningless. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/878vmc6cfb.fsf@frosties.localnet
Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
Roger Leigh rle...@codelibre.net writes:
On Wed, Dec 14, 2011 at 12:53:24PM -0500, Zachary Harris wrote:
I could be wrong, but my (admittedly stereotyped) impression of the
standard use cases is that if you've got someone who DOES want to mount
/usr separately from / (e.g. over NFS or because of a selectively
encrypted LVM), such person is more likely wanting to do so in pure
Debian, rather than, say, in Ubuntu.
This is a bit beside the point. People keep bringing up mounting /usr
over NFS. No one to date has provided a sensible use case for it.
This is because old timers (or whoever) have failed to notice a
fundamental flaw: *package management does not work with a shared /usr*.
The cluster setup I use at work uses an initramfs with all the essential
stuff in it and mounts the rest over NFS. The reason why this works is
that the / is just as shared as /usr. Just one is shared via pxe and
then other via NFS.
The reason for not having everything on NFS is to reduce network load
and that nodes should be minimally functional without NFS. Esspecially
that you can still log in as root and diagnose problems.
On a Debian there are really only two categories for partitions:
those under the control of the package manager, and those which
are not (user data etc.). Does it make sense to split package-managed
files over multiple partitions? (other than /var)
This is *the* key point. Under a package managed distribution /
and /usr are part of a *managed whole*. They can't exist separately,
even if they are on different partitions, mounted over NFS, or
whatever. It's fine that such things /work/, but we do need to
question /why/ one would do such a thing. If you're mounting /usr
over NFS, the real question is why aren't you mounting / over NFS,
which also then includes /usr?. Mounting /usr separately makes no
sense *at all*.
The same argument applies to encryption. / and /usr both contain a
selection of programs, libraries etc. If you're encrypting one, why
would you not encrypt all of it? And the same for mounting read-only.
/, specifically /etc, contains sensitive information so it has to be
encrypted. /usr on the other hand does not and encrypting it is just a
waste of cpu time.
This would actually call for having /etc a seperate (encrypted)
partition and /usr not. Encrypting /bin or /lib is indeed as useless as
/usr.
The question that needs answering is this:
what are the reasons, today, for a separate /usr?
Excluding historical practice. What real function does it have?
Does it have any reason to continue to exist?
And regarding the LSB: I checked, and it would be entirely compliant
for Debian to merge the two.
Enforce a
policy that anything being put into /sbin or /bin must pass the ldd
test. If a dependency is in /usr/lib then negotiations have to be made
to reach an agreement to either downgrade the binary to /usr/{s,}bin
or upgrade the library to /lib. (In the case of downgrading the
binary, you can say that the user of the Debian package bears the
responsibility to have ensured that the executables he personally
considers essential in his own context were accessible where he would
need them when he would need them. But the distro itself should take
responsibility for being CONSISTENT, and thus should not say, Here's
something available to you in /sbin---oh, but you can't actually use it
from there (so to speak).)
The problem here is, can we /be/ consistent? What is one system's
essential package required for bringing up a working system is
someone else's occasionally-used tool that's not important at all.
Yet both might be required to be on the rootfs. We can't be all
things to all people in the current state. But unification /would/
*guarantee* things would always work and be consistent: every
program and library would always be right there on the rootfs.
You are not reading him.
consistent == if it is in /sbin or /bin then it works without /usr.
consistent != everything even some insane user might want in / is in /.
That was exactly his point.
The status quo is a best effort. Things sometimes break, and
there's an continuing migration of essential packages to the
rootfs. Given that a modern initramfs can mount pretty much any
filesystem, either locally or over a network, what's the *real*
reason for a separate /usr? It's certainly not for any booting-
related reason.
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/874nx06brs.fsf@frosties.localnet
Re: Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
On Thu, Dec 15, 2011 at 06:19:54PM +0100, Marco d'Itri wrote:
On Dec 15, Roger Leigh rle...@codelibre.net wrote:
You keep repeating arguments in favour of moving /{bin,sbin,lib}/ to
/usr/ :-)
Well, I think I still need persuading that this is the right direction
to move the files. I still think that moving /usr to / is a better
strategy, albeit introducing some problems with users who would need
/usr to / does not allow any new features, while / to /usr allows
implementing new features like creating OS snapshots at file system
level (something which Fedora already supports) or a real complete OS
image (to be NFS-shared, replicated, etc).
I'm not quite sure I see why such new features would be dependent upon
this.
Please correct my confusion if I'm wrong, but I'm not sure I can see
why it wouldn't be possible to snapshot the rootfs whichever way we
migrate files. Both / and /usr would need to be snapshotted as a whole
in order to do proper rollbacks wouldn't they? So why would migrating
from /usr to / prevent this?
WRT mounting additional filesystems in the initramfs, how difficult
would it be to add an additional mount option to /etc/fstab entries,
e.g. init or initramfs to mark them as being required for mounting
in the initramfs. This could include /, /usr, /etc and anything else
the admin deems necessary for booting, and would just be checked and
added when creating/updating the initramfs.
/ is already mountable, while /etc obviously could not be if you want to
look at fstab. I see no compelling reasons to create standalone file
systems for the other directories, which are small and static.
If we could add an entry such as:
/dev/mapper/etc /etc ext4 initramfs 0 1
to /etc/fstab, then it could be added to a list of filesystems to be
mounted in the initramfs. Obviously a change to /etc/fstab would
require the initramfs to be updated, but when it came to mounting the
rest of the filesystems once the initramfs hands over to the rootfs
init, it could continue to use the real /etc/fstab. The only real
change would be that certain filesystems would have been pre-mounted.
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`-GPG Public Key: 0x25BFB848 Please GPG sign your mail.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111216110732.gn17...@codelibre.net
Re: Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
On Dec 16, Roger Leigh rle...@codelibre.net wrote: Please correct my confusion if I'm wrong, but I'm not sure I can see why it wouldn't be possible to snapshot the rootfs whichever way we migrate files. Both / and /usr would need to be snapshotted as a whole in order to do proper rollbacks wouldn't they? So why would migrating from /usr to / prevent this? Obviously it depends on what you are trying to do, but the interesting case for me is to snapshot the OS (/usr) but keep the data and configuration (everything else). And keeping /etc, /home and /var on a different file system to allow snapshotting / is more complex (and not really feasible for /etc). And then there is the issue of easily sharing the OS (either over the network or replicating it) while keeping distinct copies of local data. If we could add an entry such as: /dev/mapper/etc /etc ext4 initramfs 0 1 to /etc/fstab, then it could be added to a list of filesystems to be mounted in the initramfs. Obviously a change to /etc/fstab would require the initramfs to be updated, but when it came to mounting the Indeed. So this still looks like a very complex solution to a problem nobody cares about. -- ciao, Marco signature.asc Description: Digital signature
Bug#652011: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
On Wed, Dec 14, 2011 at 03:31:41PM -0600, Jonathan Nieder wrote: Two clarifications: Jonathan Nieder wrote: Roger Leigh wrote: The question that needs answering is this: what are the reasons, today, for a separate /usr? No, I don't think an answer to that precise question today would be especially helpful. I'd like to apologize for this response. Hearing use cases is always welcome, especially when they are given in the spirit of being helpful rather than defensiveness. No worries, sorry if my initial response was also rather aggressive. I would simply like to have some critical thought put into considering /why/ we have things the way they are, rather than having historical reasons as a rather unsatisfying answer, especially when those reasons may no longer be applicable. As far as I can tell, it is not especially unsensible to use separate partitions for /usr, /etc, /var, /boot, and /opt. It occured to me too late that it might sound like I am saying a /etc partition separate from / can work. By separate I only meant distinct (i.e., the /usr, /etc, /var, etc inodes all coming from different mounts). I also think I misunderstood your message. What kind of unification are you advocating? Fedora's setup, for example, allows /usr to be a separate filesystem. I'm not currently really advocating for any specific unification now. While I think in the long run it would make sense to merge the content of / and /usr, I don't think wheezy is the right time for it. We might want to do some groundwork though, such as not having duplicate paths on / and /usr. There are two different questions here: - do we want do permit /usr as a separately-mountable filesystem? - do we want /usr at all? The udev concerns the first; though being able to mount /usr in the initramfs would ameliorate that. Long-term though, we might want to do away with it entirely and leave it as a compatibility symlink (for new installs). Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111215124148.gf17...@codelibre.net
Re: Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
On Wed, Dec 14, 2011 at 10:43:38PM +0100, J.A. Bezemer wrote: On Wed, 14 Dec 2011, Roger Leigh wrote: [..] The same argument applies to encryption. / and /usr both contain a selection of programs, libraries etc. If you're encrypting one, why would you not encrypt all of it? Speed. [...] encrypted. But this actually does _not_ slow things down: the Linux disk cache is sensibly caching the decrypted data, so often-used stuff from /bin and /lib happily remains in already-decrypted cache. The interesting stuff from /usr is generally too large and too seldomly used to remain cached. This was brought up last time this came up on -devel. And I think it kind of misses the point. You are encrypting / and not encrypting /usr. That's fine. But it's a workaround. It's not addressing the *real* goal, which is to encrypt /etc. That is to say, /usr is a split of /convenience/. The real solution would be to have /etc as a separately-mounted encrypted filesystem. So really, keeping /usr separate is a different issue, IMHO. This isn't a reason to keep the /usr split, it's a reason to support mounting an encrypted /etc in the initramfs. Such a solution would also satisfy those that want a read-only root but writable /etc for admin convenience. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111215124640.gg17...@codelibre.net
Re: Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
On Dec 15, Roger Leigh rle...@codelibre.net wrote:
That is to say, /usr is a split of /convenience/. The real solution
would be to have /etc as a separately-mounted encrypted filesystem.
So really, keeping /usr separate is a different issue, IMHO. This
isn't a reason to keep the /usr split, it's a reason to support
mounting an encrypted /etc in the initramfs. Such a solution would
also satisfy those that want a read-only root but writable /etc for
admin convenience.
You keep repeating arguments in favour of moving /{bin,sbin,lib}/ to
/usr/ :-)
--
ciao,
Marco
signature.asc
Description: Digital signature
Re: Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
On Thu, Dec 15, 2011 at 01:57:20PM +0100, Marco d'Itri wrote:
On Dec 15, Roger Leigh rle...@codelibre.net wrote:
That is to say, /usr is a split of /convenience/. The real solution
would be to have /etc as a separately-mounted encrypted filesystem.
So really, keeping /usr separate is a different issue, IMHO. This
isn't a reason to keep the /usr split, it's a reason to support
mounting an encrypted /etc in the initramfs. Such a solution would
also satisfy those that want a read-only root but writable /etc for
admin convenience.
You keep repeating arguments in favour of moving /{bin,sbin,lib}/ to
/usr/ :-)
Well, I think I still need persuading that this is the right direction
to move the files. I still think that moving /usr to / is a better
strategy, albeit introducing some problems with users who would need
to resize the rootfs (but this has always been an issue with upgrades,
it's really the admin's responsibility to deal with partition sizing
prior to upgrading).
WRT mounting additional filesystems in the initramfs, how difficult
would it be to add an additional mount option to /etc/fstab entries,
e.g. init or initramfs to mark them as being required for mounting
in the initramfs. This could include /, /usr, /etc and anything else
the admin deems necessary for booting, and would just be checked and
added when creating/updating the initramfs.
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`-GPG Public Key: 0x25BFB848 Please GPG sign your mail.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111215132918.gi17...@codelibre.net
Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
Ok, ok, ok, I think I may have got it. Some of your comments helped
get me on the proper track of distro-oriented thinking where different
systems are picking and choosing a different subset of available
packages, but those packages have predefined locations where they have
to put things. It has rightly been pointed out to me by others here that
what is really needed is for libraries to be placed where they are
needed according to the a posteriori knowledge of the selection of
programs in /{s,}bin _on the local system_.
So, I realized, how about a _package_ (I propose the name fhslib) that
effectively does something like this:
1) Check ldd /{s,}bin/* for dependencies in /usr, and put copies of
of the those libraries in /lib.
2) Keep track (somewhere in /var) of what fhslib has put in /lib.
3) When other packages are installed or removed, fhslib gets
triggered to update.
Then we continue on as currently, with library package maintainers
doing their best to be reasonable in where they think a library
generally properly belongs, so that on any given system fhslib will
hopefully only duplicate a small handful of libraries to pick up the slack.
On my box fhslib would result in a reasonable redundancy of 4M:
$ ldd /{s,}bin/* | /bin/grep usr | cut -f2 -d | cut -f1 -d( |
sort -u | xargs du -Lhc ; sudo du -sh /lib ; du -sh /usr/lib
1.7M/usr/lib/libcrypto.so.0.9.8
148K/usr/lib/libdbus-glib-1.so.2
60K/usr/lib/libdiscover.so.2
168K/usr/lib/libexpat.so.1
220K/usr/lib/libfuse.so.2
288K/usr/lib/libgobject-2.0.so.0
20K/usr/lib/libgthread-2.0.so.0
68K/usr/lib/libhal.so.1
44K/usr/lib/libhal-storage.so.1
28K/usr/lib/libnfnetlink.so.0
328K/usr/lib/libnl.so.1
352K/usr/lib/libntfs-3g.so.75
160K/usr/lib/libntfs.so.10
44K/usr/lib/libpcsclite.so.1
348K/usr/lib/libssl.so.0.9.8
96K/usr/lib/libz.so.1
4.0Mtotal
370M/lib
2.1G/usr/lib
Not being a package developer (yet!?), I am naive as to how much work it
would take to put fhslib together. Unless someone else really wants to
jump on it, I'd be willing to take this as an opportunity to learn a
little Debian package management and give back to the community that has
given me so much (free beer).
-Zach
PS I think I would like fhslib to have a priority of important so that
someone who installs even a basic Debian system can expect FHS
compliancy. Indeed, in some sense it may be the most minimal systems
where it is most important.
Re: Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
On Thu, 15 Dec 2011 at 13:29:18 +, Roger Leigh wrote: ... albeit introducing some problems with users who would need to resize the rootfs (but this has always been an issue with upgrades, ... particularly if general-purpose libraries (GLib, D-Bus, OpenSSL, Expat, HAL, zlib...) gradually creep from /usr/lib into /lib over time, whenever someone wants to use them in a binary that gets run from udev. In practice, the rootfs is far from being either minimal (because in principle, every library required by any udev hook, NSS module or PAM module has to go there, regardless of whether this particular system has that module) or a complete/usable environment for system rescue (numerous Essential:yes packages are not present, including about half of coreutils and nearly all of dpkg). S -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111215140404.ga2...@reptile.pseudorandom.co.uk
Re: Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
On Thu, Dec 15, 2011 at 01:29:18PM +, Roger Leigh wrote: Well, I think I still need persuading that this is the right direction to move the files. I still think that moving /usr to / is a better strategy I think we would need a very, very good reason to migrate away from /usr. Fedora already is going the other way (/lib,bin to /usr). Going the other way would increase fragmentation in Linux and make essentially FHS history. Moving everything to /usr is also less work, no need to get rid of the --prefix=/usr in most packages in debian... Riku -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111215171753.ga32...@afflict.kos.to
Re: Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
On Dec 15, Roger Leigh rle...@codelibre.net wrote:
You keep repeating arguments in favour of moving /{bin,sbin,lib}/ to
/usr/ :-)
Well, I think I still need persuading that this is the right direction
to move the files. I still think that moving /usr to / is a better
strategy, albeit introducing some problems with users who would need
/usr to / does not allow any new features, while / to /usr allows
implementing new features like creating OS snapshots at file system
level (something which Fedora already supports) or a real complete OS
image (to be NFS-shared, replicated, etc).
WRT mounting additional filesystems in the initramfs, how difficult
would it be to add an additional mount option to /etc/fstab entries,
e.g. init or initramfs to mark them as being required for mounting
in the initramfs. This could include /, /usr, /etc and anything else
the admin deems necessary for booting, and would just be checked and
added when creating/updating the initramfs.
/ is already mountable, while /etc obviously could not be if you want to
look at fstab. I see no compelling reasons to create standalone file
systems for the other directories, which are small and static.
--
ciao,
Marco
signature.asc
Description: Digital signature
Re: Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
On Thu, Dec 15, 2011 at 07:17:53PM +0200, Riku Voipio wrote: On Thu, Dec 15, 2011 at 01:29:18PM +, Roger Leigh wrote: Well, I think I still need persuading that this is the right direction to move the files. I still think that moving /usr to / is a better strategy I think we would need a very, very good reason to migrate away from /usr. Fedora already is going the other way (/lib,bin to /usr). Going the other way would increase fragmentation in Linux and make essentially FHS history. Moving everything to /usr is also less work, no need to get rid of the --prefix=/usr in most packages in debian... Hi Riku, I think an important point to consider is that /usr would not disappear. It could be replaced by a symlink for new installs. This would permit older installs to continue to use /usr, but the files would end up on / for new installs. So no changes to --prefix would be needed, and the Debian packages themselves could still provide files in /usr. So none of this would break any FHS paths, or make us incompatible with Fedora. In both situations, the same files will be present in /bin and /usr/bin (and the same for all common subdirectories). Doing this would be a simple change to debian-installer. It might require a few other minor tweaks e.g. to dpkg-shlibdeps when considering library search paths, but this isn't new--we've already gone down this route for GNU/Hurd in the past. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111215172412.gj17...@codelibre.net
Re: Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
Roger Leigh wrote: I think an important point to consider is that /usr would not disappear. It could be replaced by a symlink for new installs. This would permit older installs to continue to use /usr, but the files would end up on / for new installs. So no changes to --prefix would be needed, and the Debian packages themselves could still provide files in /usr. Didn't the hurd port try this several years ago? My impression was that they didn't feel it had been worth the pain, perhaps it's not so easy. -- see shy jo signature.asc Description: Digital signature
Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
On 12/15/2011 09:29 PM, Roger Leigh wrote: Well, I think I still need persuading that this is the right direction to move the files. I still think that moving /usr to / is a better strategy, albeit introducing some problems with users who would need to resize the rootfs (but this has always been an issue with upgrades, it's really the admin's responsibility to deal with partition sizing prior to upgrading). This would be *really* a big issue for *a lot* of users. And I'd be one of these guys with about 100 servers to reinstall from scratch. I don't like using a /boot partition, so I have a rootfs of 1 GB of RAID1, then home, usr, var, tmp and swap mounted on LVM over RAID10. Please don't do that unless you make a special tool to resize my disks on-the-fly (eg: without shutting down my running services). Also, I really fail to see how this would be an improvement for our users. It's just an argument for making our lives of lazy library maintainer more easy. Plus having very few tools on the boot partition makes it possible to store them on a slower disk that will be less accessed than the faster one holding your /usr (see my setup above, rootfs is RAID1, /usr is on RAID10, so my /usr is faster than the rootfs). Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4eea4a14.7070...@goirand.fr
Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
On 12/16/2011 01:24 AM, Roger Leigh wrote: Hi Riku, I think an important point to consider is that /usr would not disappear. It could be replaced by a symlink for new installs. This would permit older installs to continue to use /usr, but the files would end up on / for new installs. So no changes to --prefix would be needed, and the Debian packages themselves could still provide files in /usr. Feel free to experiment such non-sense on your own computers, but please do not impose this to everyone. Oh, and when I'm at it, how do you implement /usr as read only, (over nfs for example)? This is a quite common setup in large organization / universities. Doing this would be a simple change to debian-installer. And a hell for upgrades on *a lot* of existing systems. It might require a few other minor tweaks Yeah, right... A few other minor tweaks... Good luck with them! Seriously, how much wrong could it go? Thomas Goirand (zigo) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4eea4c1b.2060...@goirand.fr
Re: Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
Le vendredi 16 décembre 2011 à 03:35 +0800, Thomas Goirand a écrit : Oh, and when I'm at it, how do you implement /usr as read only, (over nfs for example)? This is a quite common setup in large organization / universities. No, it is not. With a packaging system it is not suitable to have a NFS-shared /usr. OTOH it is a common setup to share / over NFS. -- .''`. Josselin Mouette : :' : `. `' `- signature.asc Description: This is a digitally signed message part
Re: Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
Thomas Goirand tho...@goirand.fr writes: Oh, and when I'm at it, how do you implement /usr as read only, (over nfs for example)? This is a quite common setup in large organization / universities. I really don't believe this is true any more. We used to do stuff like this and stopped doing it a long time ago, and that's what I hear from my peers. Local disk space is cheap and local package management is now easy, and doing this sort of trick is now really a waste of time and a good way to make all your computers unnecessarily slow. There are still some diskless systems, but those systems don't mount /usr over NFS. They mount / over NFS, which is a different problem entirely. Mounting /usr but not / is not a diskless configuration; it's a very rare hybrid mode with a small local disk, and now that local disk is so cheap (even with embedded devices with flash memory), it's mostly just a bad idea. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ehw5ipi2@windlord.stanford.edu
Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
On 15.12.2011 20:27, Thomas Goirand wrote: Also, I really fail to see how this would be an improvement for our users. It's just an argument for making our lives of lazy library maintainer more easy. The question is, if moving files around is a good way to spend maintainers time. I think not. Our ressources are already stretched thin, and there are better ways to invest our time. Plus having very few tools on the boot partition makes it possible to store them on a slower disk that will be less accessed than the faster one holding your /usr (see my setup above, rootfs is RAID1, /usr is on RAID10, so my /usr is faster than the rootfs). You can keep /usr on a separate partition. You just need to use an initramfs then, which will mount /usr. Adding support for that to initramfs-tools should not be too hard. dracut already supports this. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
Hi there!
On Thu, 15 Dec 2011 18:19:54 +0100, Marco d'Itri wrote:
On Dec 15, Roger Leigh rle...@codelibre.net wrote:
You keep repeating arguments in favour of moving /{bin,sbin,lib}/ to
/usr/ :-)
Well, I think I still need persuading that this is the right direction
to move the files. I still think that moving /usr to / is a better
strategy, albeit introducing some problems with users who would need
/usr to / does not allow any new features, while / to /usr allows
implementing new features like creating OS snapshots at file system
level (something which Fedora already supports) or a real complete OS
image (to be NFS-shared, replicated, etc).
Maybe a naive comment, but I would say that there should be a list of
all the benefits for any change, being it / - /usr or /usr - /, then
deciding which is the Right Thing™ would be easier (doing so we can
also document our choices).
So THANK YOU Marco for explaining (another) one for / - /usr, I was
thinking of asking Roger about it [1] before reading your reply ;-)
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=652011#93
Thx, bye,
Gismo / Luca
pgpjzNKXwDI5W.pgp
Description: PGP signature
Re: Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
On Fri, Dec 16, 2011 at 03:35:55AM +0800, Thomas Goirand wrote: On 12/16/2011 01:24 AM, Roger Leigh wrote: Hi Riku, I think an important point to consider is that /usr would not disappear. It could be replaced by a symlink for new installs. This would permit older installs to continue to use /usr, but the files would end up on / for new installs. So no changes to --prefix would be needed, and the Debian packages themselves could still provide files in /usr. Doing this would be a simple change to debian-installer. And a hell for upgrades on *a lot* of existing systems. The point of the above was to show that it could be made that upgrades would be unaffected by the change: it would only occur for new installs. I'm not saying that's the only way or the best way, just that it's one possibility to consider. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111216001730.gl17...@codelibre.net
Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
Russ Allbery writes (Re: Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib): I don't know if it's worth the effort to unify /bin and /usr/bin or the other similar things that have been discussed from time to time, The situation we have, where this is something we vaguely try to do but don't spend a lot of effort on, is IMO perfectly reasonable. For example, it would be possible for someone who wanted to make a Debian derivative which shipped with a separate /usr by default to go and fix all of these bugs, and we shouldn't make that impossible by deliberately conflating / and /usr or by rejecting the bug reports. but I do think it may be time for Debian to just officially say that we don't support /usr on a (meaningfully) separate partition from /bin and /lib, and that binaries in /bin may have dependencies on /usr/lib. If we want to relax the policy, we could say in principle we think this is a nice to have but whether to support it is up to maintainers of individual packages. Let's please not go straight to deliberately breaking it for the sake of tidiness. Ian. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20200.36851.839609.756...@chiark.greenend.org.uk
Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
Wow, if this sort of bug report is re-evoking questions on the whole
relevance of the historical FHS to modern distros, it does seem that
some real soul searching is in order on the part of the community as
far as the future of where people see Debian/GNU/Linux headed. Begin
with the end in mind, right? Not all roads lead to the same place, and
you choose a path according to where you want to end up.
Throwing my own two cents in: as far as Debian itself goes, I think
this distro ('stable', in particular) has a reputation of being a solid,
stable, rock of confidence that others can build off of and deviate
from. The center should hold, so that if something goes wrong in the
branches, the problem can hopefully be localized as quickly and
conveniently as possible.
I could be wrong, but my (admittedly stereotyped) impression of the
standard use cases is that if you've got someone who DOES want to mount
/usr separately from / (e.g. over NFS or because of a selectively
encrypted LVM), such person is more likely wanting to do so in pure
Debian, rather than, say, in Ubuntu.
In summary, I would argue that Debian's place in the world is such
that it should head down the path of fixing these FHS violations
strictly, rather than the path of loosening the policy. Give the
sys-admins who have been laboring with *nix for a couple decades a
Debian with single user mode in tip-top condition, always behaving as
it should as these foundational old-timers would see it. Enforce a
policy that anything being put into /sbin or /bin must pass the ldd
test. If a dependency is in /usr/lib then negotiations have to be made
to reach an agreement to either downgrade the binary to /usr/{s,}bin
or upgrade the library to /lib. (In the case of downgrading the
binary, you can say that the user of the Debian package bears the
responsibility to have ensured that the executables he personally
considers essential in his own context were accessible where he would
need them when he would need them. But the distro itself should take
responsibility for being CONSISTENT, and thus should not say, Here's
something available to you in /sbin---oh, but you can't actually use it
from there (so to speak).)
If someone wants a distro with a (totally?, partially?) revamped,
simplified, filesystem hierarchy that will make Linux less convoluted
and even more accessible to the wide modern market, then let them go
wild in a Debian derivative. Let Debian be the solid, faithful dad they
can go back to for advice or recovery if and when they fall or need it.
-Zach
PS Sorry if my inspirational speech here is a repetition of recent
discussion on devel lists which I don't participate in. But heck,
nobody's closed my bug report yet, so now you've got my two cents thrown
in there!
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/blu0-smtp3279a9f0484cafc80f8abc9a6...@phx.gbl
Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
On Wed, Dec 14, 2011 at 12:53:24PM -0500, Zachary Harris wrote:
Throwing my own two cents in: as far as Debian itself goes, I think
this distro ('stable', in particular) has a reputation of being a solid,
stable, rock of confidence that others can build off of and deviate
from. The center should hold, so that if something goes wrong in the
branches, the problem can hopefully be localized as quickly and
conveniently as possible.
At the same time, this does not mean that Debian should never change.
Do you have any concrete answers to the questions posed?
Merging / and /usr (in either direction) would always result in a
system with compatibility links. It's not like anything would be
broken by the change--all the paths available now would continue to
be available.
I could be wrong, but my (admittedly stereotyped) impression of the
standard use cases is that if you've got someone who DOES want to mount
/usr separately from / (e.g. over NFS or because of a selectively
encrypted LVM), such person is more likely wanting to do so in pure
Debian, rather than, say, in Ubuntu.
This is a bit beside the point. People keep bringing up mounting /usr
over NFS. No one to date has provided a sensible use case for it.
This is because old timers (or whoever) have failed to notice a
fundamental flaw: *package management does not work with a shared /usr*.
On a Debian there are really only two categories for partitions:
those under the control of the package manager, and those which
are not (user data etc.). Does it make sense to split package-managed
files over multiple partitions? (other than /var)
This is *the* key point. Under a package managed distribution /
and /usr are part of a *managed whole*. They can't exist separately,
even if they are on different partitions, mounted over NFS, or
whatever. It's fine that such things /work/, but we do need to
question /why/ one would do such a thing. If you're mounting /usr
over NFS, the real question is why aren't you mounting / over NFS,
which also then includes /usr?. Mounting /usr separately makes no
sense *at all*.
The same argument applies to encryption. / and /usr both contain a
selection of programs, libraries etc. If you're encrypting one, why
would you not encrypt all of it? And the same for mounting read-only.
The question that needs answering is this:
what are the reasons, today, for a separate /usr?
Excluding historical practice. What real function does it have?
Does it have any reason to continue to exist?
And regarding the LSB: I checked, and it would be entirely compliant
for Debian to merge the two.
Enforce a
policy that anything being put into /sbin or /bin must pass the ldd
test. If a dependency is in /usr/lib then negotiations have to be made
to reach an agreement to either downgrade the binary to /usr/{s,}bin
or upgrade the library to /lib. (In the case of downgrading the
binary, you can say that the user of the Debian package bears the
responsibility to have ensured that the executables he personally
considers essential in his own context were accessible where he would
need them when he would need them. But the distro itself should take
responsibility for being CONSISTENT, and thus should not say, Here's
something available to you in /sbin---oh, but you can't actually use it
from there (so to speak).)
The problem here is, can we /be/ consistent? What is one system's
essential package required for bringing up a working system is
someone else's occasionally-used tool that's not important at all.
Yet both might be required to be on the rootfs. We can't be all
things to all people in the current state. But unification /would/
*guarantee* things would always work and be consistent: every
program and library would always be right there on the rootfs.
The status quo is a best effort. Things sometimes break, and
there's an continuing migration of essential packages to the
rootfs. Given that a modern initramfs can mount pretty much any
filesystem, either locally or over a network, what's the *real*
reason for a separate /usr? It's certainly not for any booting-
related reason.
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`-GPG Public Key: 0x25BFB848 Please GPG sign your mail.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111214204300.ga5...@codelibre.net
Bug#652011: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
Roger Leigh wrote: The question that needs answering is this: what are the reasons, today, for a separate /usr? No, I don't think an answer to that precise question today would be especially helpful. As far as I can tell, it is not especially unsensible to use separate partitions for /usr, /etc, /var, /boot, and /opt. And whether it is sensible or not, unless you have a tool in mind that will automatically change the partitioning scheme of a running system, that's not going to help udev or crda very much. An obvious question to answer to help these programs is whether it makes sense to make /usr a separate partition and not mount it before starting init. An even more obvious question is where is the patch for initramfs-tools?. ;-) [...] The same argument applies to encryption. / and /usr both contain a selection of programs, libraries etc. If you're encrypting one, why would you not encrypt all of it? And the same for mounting read-only. Regarding mounting read-only: files in /etc change far more often than files in /usr/bin, for one thing. Hope that helps, Jonathan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111214211419.ga3...@elie.hsd1.il.comcast.net
Bug#652011: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
Two clarifications: Jonathan Nieder wrote: Roger Leigh wrote: The question that needs answering is this: what are the reasons, today, for a separate /usr? No, I don't think an answer to that precise question today would be especially helpful. I'd like to apologize for this response. Hearing use cases is always welcome, especially when they are given in the spirit of being helpful rather than defensiveness. As far as I can tell, it is not especially unsensible to use separate partitions for /usr, /etc, /var, /boot, and /opt. It occured to me too late that it might sound like I am saying a /etc partition separate from / can work. By separate I only meant distinct (i.e., the /usr, /etc, /var, etc inodes all coming from different mounts). I also think I misunderstood your message. What kind of unification are you advocating? Fedora's setup, for example, allows /usr to be a separate filesystem. Sorry for the noise, Jonathan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111214213141.ga4...@elie.hsd1.il.comcast.net
Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
On Wed, 14 Dec 2011, Roger Leigh wrote: [..] The same argument applies to encryption. / and /usr both contain a selection of programs, libraries etc. If you're encrypting one, why would you not encrypt all of it? Speed. On one of my relatively low-power portable systems, I have everything encrypted except /boot and /usr. /boot for obvious reasons; /usr because decryption is heavily CPU-bound, making encrypted /usr unworkably slow. Since encryption is for privacy reasons, I need encrypted / because of /etc. (And encrypted /home and /var of course.) Indeed, this means that programs in /bin and libs in /lib are also encrypted. But this actually does _not_ slow things down: the Linux disk cache is sensibly caching the decrypted data, so often-used stuff from /bin and /lib happily remains in already-decrypted cache. The interesting stuff from /usr is generally too large and too seldomly used to remain cached. So I'd say preferably not move /bin and /lib to /usr; but I'd say absolutely definitely not move /usr/bin and /usr/lib to /. (Well, in the latter case: unless you make sure that /bin and /lib are actually mountable separately. But that would really defeat the purpose.) Best regards, Anne Bezemer -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.lnx.4.64.1112142211520.5...@wormhole.robuust.nl
Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
On 14.12.2011 22:43, J.A. Bezemer wrote: So I'd say preferably not move /bin and /lib to /usr; but I'd say absolutely definitely not move /usr/bin and /usr/lib to /. (Well, in the latter case: unless you make sure that /bin and /lib are actually mountable separately. But that would really defeat the purpose.) Moving the bits from /lib and /(s)bin to /usr doesn't mean you won't be able to have /usr on a separate partition. It just means you'd have to use something like initramfs-tools to mount /usr for you. Actually, by moving the bits to /usr, you'd have to encrypt even less. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
On 14.12.2011 06:00, Russ Allbery wrote: I'm increasingly convinced by the recent discussion on debian-devel that doing all the (rather substantial) work required to keep this separation working is a waste of our collective time. We're not doing a very good job at it anyway, chasing all the library dependencies is a fair amount of work, and things have to keep moving around as dependencies change. And this is all to support use cases that, while real, are fairly marginal in my estimation. This does not seem like the most effective place for us to be spending our time. nod. I had to move a couple of libraries myself in the past and it's a laborious task (and I've often seen it not done right). E.g. while moving the library file to /lib, you should keep the devel files (.so symlink, .a/.la files, pkg-config files) in /usr/lib. You can't just move the .so symlink around, so you need to do it manually. The problem is, that the major build systems (autoconf/automake, cmake) don't have support for such split installations. I don't know if it's worth the effort to unify /bin and /usr/bin or the other similar things that have been discussed from time to time, but I do think it may be time for Debian to just officially say that we don't support /usr on a (meaningfully) separate partition from /bin and /lib, and that binaries in /bin may have dependencies on /usr/lib. The more I think about it, the more I like the idea to simply move everything to /usr, and make /(s)bin and /lib symlinks. While I personally never found it very useful to put /usr on a separate partition, I acknowledge that such installations are around (especially since d-i presents this partitioning scheme in such a prominent way) and we must not break such installations on upgrades. We'd have to make sure, that for such installations e.g. a initramfs is installed, which can mount /usr. That said, I'd also like to see us deprecate a separate /usr altogether. And a first step would be to update d-i to no longer present this option. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
in the given repo has chosen to put in /sbin or /bin, and
put all such binaries there. (I realize this may not(?) be possible
to do with a package manager, namely dpkg/apt, because of the
existence of conflicting packages, but rememeber I'm making a point
here with an abstract algorithmic presentation. Let's say you
manually unpack all packages and put the binary executables there in
/(s)bin.)
2) Likewise, consider the set of all libs from all packages in the
given repo and place them all in /usr/lib.
3) Run
ldd /{s,}bin/* | unique
4) Put all the libraries that appear in the output of step 3 in
/lib. All other libs can stay behind in /usr/lib (it must be that
they are only ever used by something in /usr).
Definition: We say a system satisfies the FHS-LDD property if the command
ldd /{s,}bin | grep = /usr
returns nothing.
Definition: We say a repo (or distro?) satisfies the FHS-LDD property
if _any system_ that installs a subset of the packages from that
repo/distro satisfies the FHS-LDD on that system.
My claim: A distro that uses the LPA satisfies the FHS-LDD property in
the most efficient manner possible. That is to say, it satisfies the
FHS-LDD property for that distro, and any other partitioning of
libraries between /usr/lib and /lib which would satisfy the FHS-LDD
property for this system would necessary place a set of libraries in
/lib which was a superset of that produced by LPA.
If my claim is valid, then I will have shown that there is in fact a
unique, objectively best way for libraries to be partitioned between
/usr/lib and /lib. Now, I know from professional work experience that
this is the point where the more practically grounded folks jump in and
kick my abstract mathematician legs out from underneath me and say,
Nice theorem buddy, but in the real world OK. So now to the wise
folks who said, We all have better things to be doing than this, good
on you! Kudos to anyone who ignores my bug report in favor of doing
something with their life that actually matters!
-Zach
Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
Package: general
Severity: serious
Justification: Policy 10.1.1
My understanding of the FHS would be that if a library is a dependency of a
binary in /bin or /sbin, then such library belongs in /lib, not
/usr/lib. (If
for some reason the library is also desired in /usr/lib then a sym link from
/lib to /usr/lib, but not the other way around, is acceptable.) A review of
past bug reports (e.g. #633019 and #639939 from this summer) shows that this
policy gets repeatedly violated in Debian until someone catches it.
Here is a test to reveal the current culprits on my own Squeeze
installation:
ldd /{s,}bin/* | /bin/grep usr | cut -f1 -d( | sort -u
libcrypto.so.0.9.8 = /usr/lib/libcrypto.so.0.9.8
libdbus-glib-1.so.2 = /usr/lib/libdbus-glib-1.so.2
libdiscover.so.2 = /usr/lib/libdiscover.so.2
libexpat.so.1 = /usr/lib/libexpat.so.1
libfuse.so.2 = /usr/lib/libfuse.so.2
libgobject-2.0.so.0 = /usr/lib/libgobject-2.0.so.0
libgthread-2.0.so.0 = /usr/lib/libgthread-2.0.so.0
libhal.so.1 = /usr/lib/libhal.so.1
libhal-storage.so.1 = /usr/lib/libhal-storage.so.1
libnfnetlink.so.0 = /usr/lib/libnfnetlink.so.0
libnl.so.1 = /usr/lib/libnl.so.1
libntfs-3g.so.75 = /usr/lib/libntfs-3g.so.75
libntfs.so.10 = /usr/lib/libntfs.so.10
libpcsclite.so.1 = /usr/lib/libpcsclite.so.1
libssl.so.0.9.8 = /usr/lib/libssl.so.0.9.8
libz.so.1 = /usr/lib/libz.so.1
Here is one objective test of conformity to this aspect of the FHS
requirements. The command ldd /{s,}bin/* | /bin/grep usr (or something
equivalent) should return nothing. (Well, OK, there could be weird
exceptions
where the string usr appeared in the name of an essential binary or
library,
but you get my point.)
-Zach
-- System Information:
Debian Release: 6.0.3
APT prefers stable
APT policy: (700, 'stable'), (500, 'stable-updates')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.39-bpo.2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/blu0-smtp70e86e886a077f968d6396a6...@phx.gbl
Re: Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
Zachary Harris zacharyhar...@hotmail.com writes: My understanding of the FHS would be that if a library is a dependency of a binary in /bin or /sbin, then such library belongs in /lib, not /usr/lib. (If for some reason the library is also desired in /usr/lib then a sym link from /lib to /usr/lib, but not the other way around, is acceptable.) A review of past bug reports (e.g. #633019 and #639939 from this summer) shows that this policy gets repeatedly violated in Debian until someone catches it. I'm increasingly convinced by the recent discussion on debian-devel that doing all the (rather substantial) work required to keep this separation working is a waste of our collective time. We're not doing a very good job at it anyway, chasing all the library dependencies is a fair amount of work, and things have to keep moving around as dependencies change. And this is all to support use cases that, while real, are fairly marginal in my estimation. This does not seem like the most effective place for us to be spending our time. I don't know if it's worth the effort to unify /bin and /usr/bin or the other similar things that have been discussed from time to time, but I do think it may be time for Debian to just officially say that we don't support /usr on a (meaningfully) separate partition from /bin and /lib, and that binaries in /bin may have dependencies on /usr/lib. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87vcpjbve3@windlord.stanford.edu
Re: Bug#589229: vmfs-tools: possible FHS violation, as fsck.vmfs is not in /sbin
On Thu, Jul 15, 2010 at 11:42:07PM +0200, Christoph Anton Mitterer wrote: Package: vmfs-tools Severity: serious Justification: Policy 9.1.1 Hi. I might have spotted a policy violation here (therefore the sevirity serious). Policy section 9.1.1. specifies: The location of all installed files and directories must comply with the Filesystem Hierarchy Standard (FHS), version 2.3, with the exceptions noted below,... The FHS in turn specifies: The following files, or symbolic links to files, must be in /sbin if the corresponding subsystem is installed: ... fsck.* mkfs.* (see http://www.pathname.com/fhs/pub/fhs-2.3.html#SPECIFICOPTIONS8). As far as I can tell this is not the case, right? I also do not see any exception for this in section 9.1.1. I don't judge whether /sbin is really a better location, just wanted to bring this to your attention :) That was actually done so on purpose, because while the intent is that the program is a normal fsck program, at the moment, it really doesn't do much, and doesn't work as people using /sbin/fsck would expect it to. So until the program actually does what it is intended to, I'm not exactly sure it is safe to put it in /sbin. OTOH, I could rename it, but except for nitpicking, what exactly would be the point? What do fellow developpers think? Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100716091811.gc3...@glandium.org
Re: Bug#589229: vmfs-tools: possible FHS violation, as fsck.vmfs is not in /sbin
HI! Am 16.07.2010 11:18, schrieb Mike Hommey: So until the program actually does what it is intended to, I'm not exactly sure it is safe to put it in /sbin. OTOH, I could rename it, but except for nitpicking, what exactly would be the point? What do fellow developpers think? Leaving it the way it is seems to me like a good idea. Best regards, Alexander -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c404996.7080...@schmehl.info
Re: Bug#589229: vmfs-tools: possible FHS violation, as fsck.vmfs is not in /sbin
On Fri, 2010-07-16 at 11:18 +0200, Mike Hommey wrote: So until the program actually does what it is intended to, I'm not exactly sure it is safe to put it in /sbin. OTOH, I could rename it, but except for nitpicking, what exactly would be the point? So then let's downgrade the severity and leave this open until it does what it's intended to do? Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Re: common, FHS-compliant, default document root for the various web servers
Heya, sorry for the delay.
On Sun, Nov 15, 2009 at 11:15:56PM +0100, sean finney wrote:
Inherently, such a proposal applies to static content, not CGI
applications. I fail to see where lay problems about unconfigured static
content.
read-only static content unpacked from packages is certainly not an
issue wrt being unconfigured, but i was given the impression by other
folks in this thread that the scope was not this narrow.
I might have contributed to that impression when I mentioned that
cgi-bin is already configured in some web servers. Sorry about that, the
proposal was initially for static content only, to actually find an
uniform solution to most of the outstanding RC bugs
dir-or-file-in-var-www.
Still, a related question to answer is: do we want CGIs installed under
/usr/lib/cgi-bin/ to be enabled by default? I believe currently the
answer is that they are enabled yes and no, in the sense that with
some web servers you first need to add the CGI module / handler, but
beside that they do work.
but at the same time, if we're only talking about static content at
this filesystem location, i wonder about the overall utility/benefit
of standardizing on a location in the first place. how many webapp
packages in debian consist of only read-only static content, which
would be helped by such a standardization?
wrt the issue about namespacing and default URL's (i guess this is
a seperate issue from fs location, really) i'm unconvinced about the
benefits outweighing the costs. has anyone considered putting up the
arguments for it in a DEP?
I've thought about that, but I don't have Debian time to offer alone on
that, right now. The first step would be the one you propose: testing
packages (the current dir-or-file-in-var-www buggy would be a good
start, I think) to check how many of them can be made to work by such a
change. Deciding whether CGI bin are enabled by default as asked above
of course has an impact on this.
If you are interested in working on this, we can try drafting something
together.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Re: common, FHS-compliant, default document root for the various web servers
hi stefano, On Fri, Nov 13, 2009 at 10:09:20AM +0100, Stefano Zacchiroli wrote: I understand this problem, but I think you're shooting at the wrong target. The advanced proposal (beside the aesthetically displeasing name) is about standardizing a default vendor document root on disk so that packages can install content in it, as well as defining a base URL that maps to it. Inherently, such a proposal applies to static content, not CGI applications. I fail to see where lay problems about unconfigured static content. read-only static content unpacked from packages is certainly not an issue wrt being unconfigured, but i was given the impression by other folks in this thread that the scope was not this narrow. but at the same time, if we're only talking about static content at this filesystem location, i wonder about the overall utility/benefit of standardizing on a location in the first place. how many webapp packages in debian consist of only read-only static content, which would be helped by such a standardization? wrt the issue about namespacing and default URL's (i guess this is a seperate issue from fs location, really) i'm unconvinced about the benefits outweighing the costs. has anyone considered putting up the arguments for it in a DEP? sean signature.asc Description: Digital signature
Re: common, FHS-compliant, default document root for the various web servers
Sorry for the delay in replying to this. I've just re-read all the
disagreements with the original proposal and they all seem to be related
to this main counter-argument by Sean, hence I'll reply here.
On Mon, Nov 09, 2009 at 11:50:11PM +0100, sean finney wrote:
FWIW, I'm fine with /vendor.
personally, beyond the aesthetically displeasing name, i'm really
skeptical that this will accomplish anything useful.
* most apps require extra config and splitting out of stuff into other
directories for fhs compliance anyway, thus requiring some level of
webserver configuration, meaning this adds no benefit (beyond 1 line
fewer in the server config).
* this encourages a working in unconfigured state for packages, which
seems very sketchy wrt security (similarly, to apps dropping random
publically executable scripts in /usr/lib/cgi-bin.
I understand this problem, but I think you're shooting at the wrong
target. The advanced proposal (beside the aesthetically displeasing
name) is about standardizing a default vendor document root on disk so
that packages can install content in it, as well as defining a base URL
that maps to it.
Inherently, such a proposal applies to static content, not CGI
applications. I fail to see where lay problems about unconfigured static
content.
So, regarding your working in unconfigured state I think we should
rather just be clear that CGI should not be enabled by default, if this
is actually a concern. Personally, while I understand it, I wouldn't
like carving that in stone: maintainers should be free to decide whether
their applications have a sane default that enable apps to work out of
the box or not. I easily see both apps that can work without any conf
(e.g. CGI-based doc browsers for the local machine) and apps that would
forcibly require conf (e.g. multi-intance blog engines or other
webapps).
All in all, I don't see why adding a default root for static content
make things worse wrt your problems.
A couple of other misc remarks:
- Stating that those defaults should be enabled only for the localhost
virtual host will help a lot. For web servers with no virtual host
support we can simply state that they should not have the proposed
vendor document root enabled by default.
- We already have a de facto default vendor dir rooted at /doc/, why
should this be a special case? Implementing the advanced proposal
would enable generalizing that unfortunate ad-hoc case.
Of course, thanks to all the participants for their feedback!
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Re: Possible MBF wrt common, FHS-compliant, default document root for the various web servers
On Mon, Nov 09, 2009 at 03:55:58PM -0800, Russ Allbery wrote: sean finney sean...@debian.org writes: something that hasn't really been brought up (i mentioned it on the non-webapps thread in -devel already) is that this makes packages potentially opened in an unconfigured state. unless you can ensure that the system is only running on localhost, it has some significant security implications. personally i'd rather that /usr/lib/cgi-bin goes the way of the dodo, and that packages are required to ship/generate webserver config files if they want to function out of the box. Wholeheartedly agreed, particularly if we can put a management system in place similar to the (really nice) Apache module management system that lets admins selectively enable specific applications, which installing everything into a default CGI-active directory doesn't permit as easily. Not that I'm opposing to what you're saying but... every application in the archive is configured during the installation process, possibly asking debconf questions, providing defaults etc. After the installation it should run in a mode that suites most use cases and is secure. We (or at least I) always expected that. Now with web applications, if I read you suggestions correctly, you want to just throw the files in the system, leave it unconfigured without meaningfull defaults, even leading to an unsecure state, and then blame the web server for not securing the application? Or am I misunderstanding you? Hauke signature.asc Description: Digital signature
Re: common, FHS-compliant, default document root for the various web servers
On Tue, Nov 10, 2009 at 09:49:10AM +0800, Paul Wise wrote:
On Tue, Nov 10, 2009 at 6:50 AM, sean finney sean...@debian.org wrote:
personally, beyond the aesthetically displeasing name, i'm really
skeptical that this will accomplish anything useful.
* most apps require extra config and splitting out of stuff into other
directories for fhs compliance anyway, thus requiring some level of
webserver configuration, meaning this adds no benefit (beyond 1 line
fewer in the server config).
* this encourages a working in unconfigured state for packages, which
seems very sketchy wrt security (similarly, to apps dropping random
publically executable scripts in /usr/lib/cgi-bin.
tbh this seems closer to the solution looking for a problem rather than
the other way around.
I have to agree with sean here.
I don't as I was definitely not looking for a problem but you get a full
ack. So let's talk business...
I'd instead like to see each webapp come with stuff to make a
sysadmin's life easier:
Support for multiple independent instances configured to use arbitrary
locations for data/configuration, arbitrary vhosts and arbitrary
sub-paths of those vhosts.
That means: as many files reusable by each instance as possible, those
in /usr/share/, and instance specific files in /var/{lib,cache}/package/
and /etc/package/. Right?
Scripts that can be used to setup an instance, configure it and
register it with the package and with the available and
sysadmin-selected web servers.
And I think a webapp should configure the first instance during
postinst. Applications should be able to run after installation.
Support for automatically upgrading the database structures (or
similar) for each registered instance when the package is upgraded.
This could include backups of the pre-upgrade data, disabling the
instance during the upgrade process and other things.
dbconfig-common for multiple instances? Nice idea.
Ways to easily relocate an instance; between directories on one server
and between servers.
That should be possible if web applications comply with FHS.
And my personal nitpick; PHP should be off by default so that php
scripts in configured data locations are not executed by web servers
by default. PHP files/dirs in webapp packages should be whitelisted
for execution rather than each webapp needing to blacklist their
configured data locations.
Fine with me. I'm not sure every web server supports such feature,
though.
Hauke
signature.asc
Description: Digital signature
Re: common, FHS-compliant, default document root for the various web servers
hi!
On Tue, Nov 10, 2009 at 09:29:13AM +0100, Jan Hauke Rahm wrote:
Support for multiple independent instances configured to use arbitrary
locations for data/configuration, arbitrary vhosts and arbitrary
sub-paths of those vhosts.
That means: as many files reusable by each instance as possible, those
in /usr/share/, and instance specific files in /var/{lib,cache}/package/
and /etc/package/. Right?
right. while the devil is in the details (wrt writeable on-disk files
etc), there's no technical reason why multiple instances can't be supported
by a single installation. the existing code in webapps-common should have
(very basic) examples of doing this even. what's missing from there is
support for creating per-instance /var/{lib,cache}/foo subdirectories,
but there's not a huge technical problem there either.
Scripts that can be used to setup an instance, configure it and
register it with the package and with the available and
sysadmin-selected web servers.
And I think a webapp should configure the first instance during
postinst. Applications should be able to run after installation.
yes. i'm all for sane defaults out of the box.
Support for automatically upgrading the database structures (or
similar) for each registered instance when the package is upgraded.
This could include backups of the pre-upgrade data, disabling the
instance during the upgrade process and other things.
dbconfig-common for multiple instances? Nice idea.
dbconfig-common already has some under-the-hood support for multiple
instances, even :) it's not in the documentation because it's pretty
experimental but webapps-common was using it.
Ways to easily relocate an instance; between directories on one server
and between servers.
That should be possible if web applications comply with FHS.
right. it *should* be a matter of dropping in multiple httpd config files,
which point the app at different app config files, which in turn specify
different subdirectories of the FHS-compliant locations of non-read-only
data. of course *should* doesn't necessarily imply *is* :)
And my personal nitpick; PHP should be off by default so that php
scripts in configured data locations are not executed by web servers
by default. PHP files/dirs in webapp packages should be whitelisted
for execution rather than each webapp needing to blacklist their
configured data locations.
Fine with me. I'm not sure every web server supports such feature,
though.
someone ought to file a wishlist bug against php5. at the very least there
could be a debconf prompt controlling the global status of php, and i think
there's a strong case for arguing that apps shouldn't assume that it's on
by default.
sean
--
signature.asc
Description: Digital signature
Re: common, FHS-compliant, default document root for the various web servers
On Tuesday 10 November 2009, sean finney wrote: someone ought to file a wishlist bug against php5. at the very least there could be a debconf prompt controlling the global status of php, and i think there's a strong case for arguing that apps shouldn't assume that it's on by default. I have filed #555606 for that. Everybody interested may post their thoughts there. I would especially like to have php disabled for userdirs by default. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Possible MBF wrt common, FHS-compliant, default document root for the various web servers
I haven't read all of the thread yet, but: On Monday 09 November 2009, Jan Hauke Rahm wrote: Now, I'm willing to run this, i.e. file bugs against web servers, wait for them to be fixed, then file bugs against web applications (if needed, I'm right now looking into a way to make a lintian check for it, e.g. package-with-section-web-but-no-files-in-canonical-docroot). But I don't feel like we're having a clear consensus here, do we? Well, defining consensus is always a tricky business :), but I haven't heard significant voices against, am I wrong? I'd personally proceed as follow: write a draft document (even a very brief one!) which summarizes the proposal so that people do not need to dig into the thread to follow the evolution. Once we have it, re-post it to the relevant lists (I'd say -devel, -policy, -webapps) and ask for comments. I'll try to come up with something within the next 24 hours. Don't know yet if it's gonna be a DEP or just another mail but summarizing what we got so far sounds like a plan. I think it would be best to have a wiki page that lists the problems you are trying to solve and also possible pitfalls that have to be taken into account. Then it is easier to check if a proposed solution would solve the problems while not breaking anything else. One of the pitfalls is apache2-suexec. It has the document root compiled in and doesn't allow more than one document root. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Possible MBF wrt common, FHS-compliant, default document root for the various web servers
On Sat, Nov 07, 2009 at 03:23:22PM +0100, Jan Hauke Rahm wrote: Full ack, and I even like /usr/share/www. It's easy to understand and pretty unprobable that we'd have a package called www in the archive some day needing this location. Sorry, I have to disagree with this approach. We would easily end up with items in /usr/share/www/bugzilla and also in /usr/share/bugzilla, how would you handle .inc files, for example? - Regarding the URL that would be mapped to that dir, I don't particularly like /debian/ (even though I've advanced it). However the alternative solutions I can come up with (e.g. /packages/) are actually uglier. So I guess /debian/ can stay. Some of the -webapps people can probably come up with wiser suggestions ... Manoj suggested '/vendor-apps' and I like that. It says what it should say and doesn't steal any probable path. I'm sorry, but I really don't see what this is trying to solve. From 5.1.1 of the webapps policy: Web applications should be completely agnostic of the global document root. Both the above two points also cause issues with vhosting. How would you register bugzilla with domain foo.bar, but not wibble.baz? Many of these issues were discussed back in 2005 on the debian-webapps list, leading to the webapps policy paper. It's a good read, please make sure that you're aware of it :) Neil -- blarson I use three different operating systems: Sarge, Etch, and Sid. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Possible MBF wrt common, FHS-compliant, default document root for the various web servers
Jan Hauke Rahm j...@debian.org writes: On Mon, Nov 09, 2009 at 03:55:58PM -0800, Russ Allbery wrote: sean finney sean...@debian.org writes: something that hasn't really been brought up (i mentioned it on the non-webapps thread in -devel already) is that this makes packages potentially opened in an unconfigured state. unless you can ensure that the system is only running on localhost, it has some significant security implications. personally i'd rather that /usr/lib/cgi-bin goes the way of the dodo, and that packages are required to ship/generate webserver config files if they want to function out of the box. Wholeheartedly agreed, particularly if we can put a management system in place similar to the (really nice) Apache module management system that lets admins selectively enable specific applications, which installing everything into a default CGI-active directory doesn't permit as easily. Not that I'm opposing to what you're saying but... every application in the archive is configured during the installation process, possibly asking debconf questions, providing defaults etc. After the installation it should run in a mode that suites most use cases and is secure. We (or at least I) always expected that. Now with web applications, if I read you suggestions correctly, you want to just throw the files in the system, leave it unconfigured without meaningfull defaults, even leading to an unsecure state, and then blame the web server for not securing the application? Or am I misunderstanding you? No, as Sean says, I would enable the /vendor path and all applications by default. What I want is a management system wherein one can selectively enable or disable applications and where one can change (as a system-wide default) the default installation behavior of new applications to leave them unconfigured. That way, on my servers I can say to not configure applications by default and have control over what I enable and how, but those who want installed applications to just work can use the defaults and have them be enabled automatically. I think that would mean everyone would get what they want. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: common, FHS-compliant, default document root for the various web servers
On Fri, Nov 06, 2009 at 06:53:32PM -0600, Manoj Srivastava wrote:
Something short, generic and distro-neutral like /app/ would be my
personal preference if I were developing a standard for my servers.
Unfortunately, going that direction as also increases the chances of
remapping a path the admin was already using...
/vendor-apps/ ?
I find it ugly (de gustibus), but that's not really an argument;
moreover your suggestion perfectly embodies the proper meaning of that
URL prefix.
To try making it a bit less ugly (and hard to type due to the moving
nature of - as others have pointed out), I just try to mediate with
/vendor/.
Given that such a prefix would actually be non Debian-specific, if we
settle with it I believe it would be a good idea to try pushing it
outside our borders, for instance proposing it on the
distributi...@freedesktop list.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Re: Possible MBF wrt common, FHS-compliant, default document root for the various web servers
On Sat, Nov 07, 2009 at 03:23:22PM +0100, Jan Hauke Rahm wrote:
1. If we have a generic location for packages to drop their
html/php/whatever files, like /var/lib/www, all web servers can keep
their DocRoot as /var/www and provide an alias for /var/lib/www, for
instance /debian. That way webapp packages don't even have to care
about the web server in charge, we don't need a webapps-common, we
just need all web servers to provide that alias (or if they can't,
they have to symlink it). Every webapp would be available at
localhost/debian/webapp. Since it's either a symlink or a conffile
that makes this /debian alias, it can be changed by the local
sysadmin without any risks and without touching our packages data.
I only have a couple of remarks on some details:
- According to FHS, /var/lib/ is for variable state information. As we
are talking about static HTML content, which only change upon package
upgrade, I believe it would not be appropriate. A better place would
probably be /usr/share/www/PACKAGE/ (maybe some FHS guru can give us
some insights here ...)
Full ack, and I even like /usr/share/www. It's easy to understand and
pretty unprobable that we'd have a package called www in the archive
some day needing this location.
Fine, it seems we're done with this aspect then.
- Regarding the URL that would be mapped to that dir, I don't
particularly like /debian/ (even though I've advanced it). However the
alternative solutions I can come up with (e.g. /packages/) are
actually uglier. So I guess /debian/ can stay. Some of the -webapps
people can probably come up with wiser suggestions ...
Manoj suggested '/vendor-apps' and I like that. It says what it should
say and doesn't steal any probable path.
Right, but it is possibly hard to type and a bit ugly, I've
counter-proposed /vendor/ (see my separate mail on that).
I still see a problem with the upgrade path for existing installations.
I might be wrong but I think the most difficult cases are very custom
setups with lots of changes by the local admin. I'm thinking of e.g.
webmail.domain.tld being a virtual host with DocRoot
/usr/share/squirrelmail. If the files there move to
/usr/share/www/squirrelmail we break a lot of setups. So, what about
shipping a symlink from the old location to the new one as a migration
path? This doesn't solve the very default (e.g. users accessing
squirrelmail via localhost/squirrelmail) but that is so easily solved
via alias directive or symlink that I suppose a NEWS.Debian entry would
fit best here.
What do you say?
I think that migrations from complex setup to this new setup will stay
complex no matter what we do. Also, it is not really something we can
standardize upon as migrations are very specific to each involved
packages and will ultimately be dealed with by single maintainers. So
I'd refrain to propose a generic upgrade path and just describe the new
situation we want to obtain.
Now, I'm willing to run this, i.e. file bugs against web servers, wait
for them to be fixed, then file bugs against web applications (if
needed, I'm right now looking into a way to make a lintian check for it,
e.g. package-with-section-web-but-no-files-in-canonical-docroot). But I
don't feel like we're having a clear consensus here, do we?
Well, defining consensus is always a tricky business :), but I haven't
heard significant voices against, am I wrong? I'd personally proceed as
follow: write a draft document (even a very brief one!) which summarizes
the proposal so that people do not need to dig into the thread to follow
the evolution. Once we have it, re-post it to the relevant lists (I'd
say -devel, -policy, -webapps) and ask for comments.
Actually, your suggested MBF text can pretty much be that document. If
it were me, I'd open a DEP on that just because I fear losing track of
it, but YMMV.
Attached is a suggestion for MBF as well as a dd-list of all relevant
web servers (if I did my job right).
Wow, thanks!
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Re: Possible MBF wrt common, FHS-compliant, default document root for the various web servers
On Sun, Nov 08, 2009 at 12:09:28AM +0900, Charles Plessy wrote:
For new packages, grouping everything in /usr/share/www sounds like a good
idea. The alias name, « vendor », I find a bit disturbing because we do not
sell anything. But picking the name will be the priviledge of the Do-o-crat
who
will lead the transition, I presume.
Well, it is actually pretty common in cross-distro lingo, Debian is a
vendor as well as pretty much every other distro is. The advantage of
settling on such a name IMO would be a higher chance in making it
popular in other distros. Also, it is a name that I _think_ is pretty
unlike to be used by local admins.
Still, having /usr/share/www as a document root does not prevent complex
packages to be fragmented between /usr/share, /usr/lib/cgi-bin/, /var/lib/,
/var/tmp, /var/run and /etc. Maybe you can double-check how many web servers
are able to cope with that before starting to invest a lot of time. Otherwise,
since shipping configuration files in /etc/webserver/conf.d will still be
necessary for these packages to work, there will little benefit in moving
files
to /usr/share/www.
I don't understand this argument. Sure, complex packages will be split
in several dirs, our policy states the rule for that to happen. The
whole point of this standardization is to have a single URL prefix under
which _entry_points_ for shipped web applications can be found, no
matter how the applications are deployed on the filesystem. I found such
a goal worthwhile by itself and orthogonal to the other concern you
raise.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Re: Possible MBF wrt common, FHS-compliant, default document root for the various web servers
Le Mon, Nov 09, 2009 at 10:24:39AM +0100, Stefano Zacchiroli a écrit : On Sun, Nov 08, 2009 at 12:09:28AM +0900, Charles Plessy wrote: Still, having /usr/share/www as a document root does not prevent complex packages to be fragmented between /usr/share, /usr/lib/cgi-bin/, /var/lib/, /var/tmp, /var/run and /etc. Maybe you can double-check how many web servers are able to cope with that before starting to invest a lot of time. Otherwise, since shipping configuration files in /etc/webserver/conf.d will still be necessary for these packages to work, there will little benefit in moving files to /usr/share/www. I don't understand this argument. Sure, complex packages will be split in several dirs, our policy states the rule for that to happen. The whole point of this standardization is to have a single URL prefix under which _entry_points_ for shipped web applications can be found, no matter how the applications are deployed on the filesystem. I found such a goal worthwhile by itself and orthogonal to the other concern you raise. Hi Stefano, the lintian error dir-or-file-in-var-www exists for a long time, and I believe that most packages with active maintainers have already been split according to the FHS. What I question is whether it is worth the effort to move the content of /usr/share/package to /usr/share/www/package: - How many purely static websites do we distribute as Debian packages? (Note that /usr/share/doc/package is already served as http://localhost/doc/package/) - How many dynamic websites will start to work out of the box without the need for a specific configuration for each webserver? I checked at the web application I maintain (emboss-explorer), and in its particular case, it would still need an apache.conf file. That is not enough to make statistics, so I am just asking if there will be many packages that can take advantage of the proposed reorganisation. [And unfortunately source.debian.net looks borken again…]. Of course, if the use of /usr/share/www/package is optional, everybody wins. Cheers, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: common, FHS-compliant, default document root for the various web servers
On Mon, Nov 09, 2009 at 10:15:00AM +0100, Stefano Zacchiroli wrote: On Fri, Nov 06, 2009 at 06:53:32PM -0600, Manoj Srivastava wrote: Something short, generic and distro-neutral like /app/ would be my personal preference if I were developing a standard for my servers. Unfortunately, going that direction as also increases the chances of remapping a path the admin was already using... /vendor-apps/ ? I find it ugly (de gustibus), but that's not really an argument; moreover your suggestion perfectly embodies the proper meaning of that URL prefix. To try making it a bit less ugly (and hard to type due to the moving nature of - as others have pointed out), I just try to mediate with /vendor/. FWIW, I'm fine with /vendor. Given that such a prefix would actually be non Debian-specific, if we settle with it I believe it would be a good idea to try pushing it outside our borders, for instance proposing it on the distributi...@freedesktop list. Just sent it to freestandards-fhs-disc...@lists.sourceforge.net. Let's see if someone else is interested in this... :) Hauke signature.asc Description: Digital signature
Re: Possible MBF wrt common, FHS-compliant, default document root for the various web servers
On Mon, Nov 09, 2009 at 10:21:12AM +0100, Stefano Zacchiroli wrote: On Sat, Nov 07, 2009 at 03:23:22PM +0100, Jan Hauke Rahm wrote: I still see a problem with the upgrade path for existing installations. I might be wrong but I think the most difficult cases are very custom setups with lots of changes by the local admin. I'm thinking of e.g. webmail.domain.tld being a virtual host with DocRoot /usr/share/squirrelmail. If the files there move to /usr/share/www/squirrelmail we break a lot of setups. So, what about shipping a symlink from the old location to the new one as a migration path? This doesn't solve the very default (e.g. users accessing squirrelmail via localhost/squirrelmail) but that is so easily solved via alias directive or symlink that I suppose a NEWS.Debian entry would fit best here. What do you say? I think that migrations from complex setup to this new setup will stay complex no matter what we do. Also, it is not really something we can standardize upon as migrations are very specific to each involved packages and will ultimately be dealed with by single maintainers. So I'd refrain to propose a generic upgrade path and just describe the new situation we want to obtain. I agree, I was just pointing out that common setups can have a proper migration path. We could give a hint when we're at it but the maintainer needs to think of something him/herself after all. Now, I'm willing to run this, i.e. file bugs against web servers, wait for them to be fixed, then file bugs against web applications (if needed, I'm right now looking into a way to make a lintian check for it, e.g. package-with-section-web-but-no-files-in-canonical-docroot). But I don't feel like we're having a clear consensus here, do we? Well, defining consensus is always a tricky business :), but I haven't heard significant voices against, am I wrong? I'd personally proceed as follow: write a draft document (even a very brief one!) which summarizes the proposal so that people do not need to dig into the thread to follow the evolution. Once we have it, re-post it to the relevant lists (I'd say -devel, -policy, -webapps) and ask for comments. I'll try to come up with something within the next 24 hours. Don't know yet if it's gonna be a DEP or just another mail but summarizing what we got so far sounds like a plan. Hauke signature.asc Description: Digital signature
Re: Possible MBF wrt common, FHS-compliant, default document root for the various web servers
On Mon, Nov 09, 2009 at 07:04:22PM +0900, Charles Plessy wrote:
the lintian error dir-or-file-in-var-www exists for a long time, and I
believe that most packages with active maintainers have already been
split according to the FHS. What I question is whether it is worth the
effort to move the content of /usr/share/package to
/usr/share/www/package:
- How many purely static websites do we distribute as Debian packages?
(Note that /usr/share/doc/package is already served as
http://localhost/doc/package/)
- How many dynamic websites will start to work out of the box without
the need for a specific configuration for each webserver?
I now understand better your argument, thanks for rephrasing. I don't
have an answer, because I haven't done the test, but I do agree that it
would be interesting to know in advance. Still, it is not exactly clear
to me how to test this, how would you automatically discover whether a
package has a static splash screen (note indeed that it is not only
about purely static web applications, but also about regular
webapps, with a static splash screen).
I checked at the web application I maintain (emboss-explorer), and in its
particular case, it would still need an apache.conf file. That is not enough
to
make statistics, so I am just asking if there will be many packages that can
take advantage of the proposed reorganisation. [And unfortunately
source.debian.net
looks borken again…].
Can you perhaps explain why so?
I frankly hope that with /vendor/ + /usr/lib/cgi-bin/ (which we already
have), and maybe with some symlinks under /vendor/ we will be able to
address quite a lot of issues. It would be interesting to known which
one we can't.
Now that I think of it, probably a per-package data dir would help, but
that can be a tad more tricky due to single-instance of
multiple-instance nature of the webapp in question ...
Of course, if the use of /usr/share/www/package is optional,
everybody wins.
It is forcibly optional: if you have some static content you should use,
otherwise not.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Re: common, FHS-compliant, default document root for the various web servers
hi guys, On Mon, Nov 09, 2009 at 02:56:59PM +0100, Jan Hauke Rahm wrote: To try making it a bit less ugly (and hard to type due to the moving nature of - as others have pointed out), I just try to mediate with /vendor/. FWIW, I'm fine with /vendor. personally, beyond the aesthetically displeasing name, i'm really skeptical that this will accomplish anything useful. * most apps require extra config and splitting out of stuff into other directories for fhs compliance anyway, thus requiring some level of webserver configuration, meaning this adds no benefit (beyond 1 line fewer in the server config). * this encourages a working in unconfigured state for packages, which seems very sketchy wrt security (similarly, to apps dropping random publically executable scripts in /usr/lib/cgi-bin. tbh this seems closer to the solution looking for a problem rather than the other way around. sean -- signature.asc Description: Digital signature
Re: Possible MBF wrt common, FHS-compliant, default document root for the various web servers
On Mon, Nov 09, 2009 at 06:15:42PM +0100, Stefano Zacchiroli wrote: I frankly hope that with /vendor/ + /usr/lib/cgi-bin/ (which we already have), and maybe with some symlinks under /vendor/ we will be able to address quite a lot of issues. It would be interesting to known which one we can't. objection, you honor! :) something that hasn't really been brought up (i mentioned it on the non-webapps thread in -devel already) is that this makes packages potentially opened in an unconfigured state. unless you can ensure that the system is only running on localhost, it has some significant security implications. personally i'd rather that /usr/lib/cgi-bin goes the way of the dodo, and that packages are required to ship/generate webserver config files if they want to function out of the box. sean signature.asc Description: Digital signature
Re: Possible MBF wrt common, FHS-compliant, default document root for the various web servers
sean finney sean...@debian.org writes: something that hasn't really been brought up (i mentioned it on the non-webapps thread in -devel already) is that this makes packages potentially opened in an unconfigured state. unless you can ensure that the system is only running on localhost, it has some significant security implications. personally i'd rather that /usr/lib/cgi-bin goes the way of the dodo, and that packages are required to ship/generate webserver config files if they want to function out of the box. Wholeheartedly agreed, particularly if we can put a management system in place similar to the (really nice) Apache module management system that lets admins selectively enable specific applications, which installing everything into a default CGI-active directory doesn't permit as easily. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: common, FHS-compliant, default document root for the various web servers
On Tue, Nov 10, 2009 at 6:50 AM, sean finney sean...@debian.org wrote: personally, beyond the aesthetically displeasing name, i'm really skeptical that this will accomplish anything useful. * most apps require extra config and splitting out of stuff into other directories for fhs compliance anyway, thus requiring some level of webserver configuration, meaning this adds no benefit (beyond 1 line fewer in the server config). * this encourages a working in unconfigured state for packages, which seems very sketchy wrt security (similarly, to apps dropping random publically executable scripts in /usr/lib/cgi-bin. tbh this seems closer to the solution looking for a problem rather than the other way around. I have to agree with sean here. I'd instead like to see each webapp come with stuff to make a sysadmin's life easier: Support for multiple independent instances configured to use arbitrary locations for data/configuration, arbitrary vhosts and arbitrary sub-paths of those vhosts. Scripts that can be used to setup an instance, configure it and register it with the package and with the available and sysadmin-selected web servers. Support for automatically upgrading the database structures (or similar) for each registered instance when the package is upgraded. This could include backups of the pre-upgrade data, disabling the instance during the upgrade process and other things. Ways to easily relocate an instance; between directories on one server and between servers. And my personal nitpick; PHP should be off by default so that php scripts in configured data locations are not executed by web servers by default. PHP files/dirs in webapp packages should be whitelisted for execution rather than each webapp needing to blacklist their configured data locations. I imagine DSA have a couple of things that could be added to the above wishlist. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Possible MBF wrt common, FHS-compliant, default document root for the various web servers
On Sat, 7 Nov 2009, Jan Hauke Rahm wrote: Caudium can and will adjust to any standard that the community agrees upon and it can handle different directories without problem. I really dont have that much input for how this should be done but leaving it as it is now is worse. Thanks for your response, Charles! On Sun, Nov 08, 2009 at 12:09:28AM +0900, Charles Plessy wrote: As a maintainer of a web application, I share your worries. I never had any user request to make it work out of the box with alternative web servers, so I guess that my users have nothing to gain and everything to lose in a change. I strongly suggest that the transition is experimented on a few volunteer packages before increasing the workload of many persons ? users and developers. I think this is a bit black or white. Users (ar rather admins) gain the possibility to easily guess where a package is to be found. No looking for /usr/share/package/html or something, just assume it's /usr/share/www/package. And they don't lose everything, they just need to read the chapter (yet to be written, of course) in the release notes about web applications being moved; additionally NEWS.Debian should be provided by any relevant package and so on. Also, I said, a proper migration path has still to be figured out. The question for now is: do we want this change at all and -- if so -- shall I file bugs against the web servers. I'd suggest severity wishlist for the start. For new packages, grouping everything in /usr/share/www sounds like a good idea. The alias name, « vendor », I find a bit disturbing because we do not sell anything. But picking the name will be the priviledge of the Do-o-crat who will lead the transition, I presume. Well, I find 'vendor' a bit confusing as well but I'm not a native english speaker and I don't have better ideas. Shoot if you have any. Something like 'debian', 'webapps', 'applications' seem way to generic for this. Still, having /usr/share/www as a document root does not prevent complex packages to be fragmented between /usr/share, /usr/lib/cgi-bin/, /var/lib/, /var/tmp, /var/run and /etc. Maybe you can double-check how many web servers are able to cope with that before starting to invest a lot of time. Otherwise, since shipping configuration files in /etc/webserver/conf.d will still be necessary for these packages to work, there will little benefit in moving files to /usr/share/www. And there isn't even a way we could (or want to) solve this. Applications of many sorts have to deal with FHS, webapps are nothing special in that matter. We can't allow an admin to fiddle aroung with files in /usr/share, nor can we just pump all webapps into /var as this will break (or at least bloat) many backup strategies and cause other problems. Until now I thought simple symlinks work with every webserver and thus didn't see a problem for that. It's the application that sometimes needs patching to deal with its being splattered around. Am I wrong here? Hauke
Possible MBF wrt common, FHS-compliant, default document root for the various web servers
On Thu, Nov 05, 2009 at 04:39:06PM +0100, Stefano Zacchiroli wrote: On Thu, Nov 05, 2009 at 10:21:48AM +0100, Jan Hauke Rahm wrote: Okay, I understand. Now, I see two ways actually to solve this. 1. If we have a generic location for packages to drop their html/php/whatever files, like /var/lib/www, all web servers can keep their DocRoot as /var/www and provide an alias for /var/lib/www, for instance /debian. That way webapp packages don't even have to care about the web server in charge, we don't need a webapps-common, we just need all web servers to provide that alias (or if they can't, they have to symlink it). Every webapp would be available at localhost/debian/webapp. Since it's either a symlink or a conffile that makes this /debian alias, it can be changed by the local sysadmin without any risks and without touching our packages data. 2. If however all packages put their files in different locations, we need your suggested solution with scripts for each webserver. A package like webapps-common could run foreach server in /usr/share/webapps-common/webservers/*; do ./$server webappPath webappName done and the web servers provide aliases/symlinks accordingly. So, what's wrong with (1) that we don't go this simple path? Fair question. As I can't came up with an answer, I guess that (1) is indeed a better solution, due Occam's razor. I only have a couple of remarks on some details: - According to FHS, /var/lib/ is for variable state information. As we are talking about static HTML content, which only change upon package upgrade, I believe it would not be appropriate. A better place would probably be /usr/share/www/PACKAGE/ (maybe some FHS guru can give us some insights here ...) Full ack, and I even like /usr/share/www. It's easy to understand and pretty unprobable that we'd have a package called www in the archive some day needing this location. - Regarding the URL that would be mapped to that dir, I don't particularly like /debian/ (even though I've advanced it). However the alternative solutions I can come up with (e.g. /packages/) are actually uglier. So I guess /debian/ can stay. Some of the -webapps people can probably come up with wiser suggestions ... Manoj suggested '/vendor-apps' and I like that. It says what it should say and doesn't steal any probable path. I still see a problem with the upgrade path for existing installations. I might be wrong but I think the most difficult cases are very custom setups with lots of changes by the local admin. I'm thinking of e.g. webmail.domain.tld being a virtual host with DocRoot /usr/share/squirrelmail. If the files there move to /usr/share/www/squirrelmail we break a lot of setups. So, what about shipping a symlink from the old location to the new one as a migration path? This doesn't solve the very default (e.g. users accessing squirrelmail via localhost/squirrelmail) but that is so easily solved via alias directive or symlink that I suppose a NEWS.Debian entry would fit best here. What do you say? Now, I'm willing to run this, i.e. file bugs against web servers, wait for them to be fixed, then file bugs against web applications (if needed, I'm right now looking into a way to make a lintian check for it, e.g. package-with-section-web-but-no-files-in-canonical-docroot). But I don't feel like we're having a clear consensus here, do we? Attached is a suggestion for MBF as well as a dd-list of all relevant web servers (if I did my job right). Now critizise! Hauke Subject: Install alias '/vendor-apps' to /usr/share/www as canonical DocRoot for packaged web applications Package: apache2 Severity: wishlist User: j...@debian.org Usertags: canonicaldocroot-server Dear maintainer, when discussing the appropriate location for web application files it was suggested to have one canonical location for those in the file system that all these web applications should use. All web servers in the archive should support this decision by providing a default way to access this location. It is consensus in debian-de...@l.d.o that this location shall be /usr/share/www and packages are supposed to drop their files in subdirectories, i.e. /usr/share/www/package (If a web application additionally needs files that are auto-generated and/or to be touched by local admins or users, the application itself should cope with that and provide a proper location for that, i.e. probably '/var/lib/package/html' or similar.) As a default this location shall be accessable via http://localhost/vendor-apps/package If this web server has an alias functionality it is best to use that as conffiles are the easiest way for admins to adjust the setup to their needs. If, however, such a functionality is not given, a symlink /var/www/vendor-apps - /usr/share/www may solve the problem. If this web servers *needs* the target of a symlink or alias
Re: Possible MBF wrt common, FHS-compliant, default document root for the various web servers
Le Sat, Nov 07, 2009 at 03:23:22PM +0100, Jan Hauke Rahm a écrit : I still see a problem with the upgrade path for existing installations. I might be wrong but I think the most difficult cases are very custom setups with lots of changes by the local admin. I'm thinking of e.g. webmail.domain.tld being a virtual host with DocRoot /usr/share/squirrelmail. If the files there move to /usr/share/www/squirrelmail we break a lot of setups. So, what about shipping a symlink from the old location to the new one as a migration path? This doesn't solve the very default (e.g. users accessing squirrelmail via localhost/squirrelmail) but that is so easily solved via alias directive or symlink that I suppose a NEWS.Debian entry would fit best here. What do you say? Dear Hauke, As a maintainer of a web application, I share your worries. I never had any user request to make it work out of the box with alternative web servers, so I guess that my users have nothing to gain and everything to lose in a change. I strongly suggest that the transition is experimented on a few volunteer packages before increasing the workload of many persons – users and developers. For new packages, grouping everything in /usr/share/www sounds like a good idea. The alias name, « vendor », I find a bit disturbing because we do not sell anything. But picking the name will be the priviledge of the Do-o-crat who will lead the transition, I presume. Still, having /usr/share/www as a document root does not prevent complex packages to be fragmented between /usr/share, /usr/lib/cgi-bin/, /var/lib/, /var/tmp, /var/run and /etc. Maybe you can double-check how many web servers are able to cope with that before starting to invest a lot of time. Otherwise, since shipping configuration files in /etc/webserver/conf.d will still be necessary for these packages to work, there will little benefit in moving files to /usr/share/www. Anyway, thank you very much for your initiative. Exploring new directions is good ! Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: common, FHS-compliant, default document root for the various web servers
On Fri, Nov 06, 2009 at 06:53:32PM -0600, Manoj Srivastava wrote: On Fri, Nov 06 2009, The Fungi wrote: On Fri, Nov 06, 2009 at 01:11:47PM +0100, Harald Braumann wrote: /debian/ seems to be the de facto standard for Debian archives. So I guess it wouldn't be such a good idea to use it for something else (sorry, can't really come up with a better name myself). Something short, generic and distro-neutral like /app/ would be my personal preference if I were developing a standard for my servers. Unfortunately, going that direction as also increases the chances of remapping a path the admin was already using... /vendor-apps/ ? To see your locally-installed documentation, use: http://localhost/vendor-apps/dwww -- Tzafrir Cohen | tzaf...@jabber.org | VIM is http://tzafrir.org.il || a Mutt's tzaf...@cohens.org.il || best ICQ# 16849754 || friend -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Possible MBF wrt common, FHS-compliant, default document root for the various web servers
Thanks for your response, Charles! On Sun, Nov 08, 2009 at 12:09:28AM +0900, Charles Plessy wrote: As a maintainer of a web application, I share your worries. I never had any user request to make it work out of the box with alternative web servers, so I guess that my users have nothing to gain and everything to lose in a change. I strongly suggest that the transition is experimented on a few volunteer packages before increasing the workload of many persons – users and developers. I think this is a bit black or white. Users (ar rather admins) gain the possibility to easily guess where a package is to be found. No looking for /usr/share/package/html or something, just assume it's /usr/share/www/package. And they don't lose everything, they just need to read the chapter (yet to be written, of course) in the release notes about web applications being moved; additionally NEWS.Debian should be provided by any relevant package and so on. Also, I said, a proper migration path has still to be figured out. The question for now is: do we want this change at all and -- if so -- shall I file bugs against the web servers. I'd suggest severity wishlist for the start. For new packages, grouping everything in /usr/share/www sounds like a good idea. The alias name, « vendor », I find a bit disturbing because we do not sell anything. But picking the name will be the priviledge of the Do-o-crat who will lead the transition, I presume. Well, I find 'vendor' a bit confusing as well but I'm not a native english speaker and I don't have better ideas. Shoot if you have any. Something like 'debian', 'webapps', 'applications' seem way to generic for this. Still, having /usr/share/www as a document root does not prevent complex packages to be fragmented between /usr/share, /usr/lib/cgi-bin/, /var/lib/, /var/tmp, /var/run and /etc. Maybe you can double-check how many web servers are able to cope with that before starting to invest a lot of time. Otherwise, since shipping configuration files in /etc/webserver/conf.d will still be necessary for these packages to work, there will little benefit in moving files to /usr/share/www. And there isn't even a way we could (or want to) solve this. Applications of many sorts have to deal with FHS, webapps are nothing special in that matter. We can't allow an admin to fiddle aroung with files in /usr/share, nor can we just pump all webapps into /var as this will break (or at least bloat) many backup strategies and cause other problems. Until now I thought simple symlinks work with every webserver and thus didn't see a problem for that. It's the application that sometimes needs patching to deal with its being splattered around. Am I wrong here? Hauke signature.asc Description: Digital signature
Re: common, FHS-compliant, default document root for the various web servers
Le Sat, Nov 07, 2009 at 04:16:54PM +, Tzafrir Cohen a écrit : To see your locally-installed documentation, use: http://localhost/vendor-apps/dwww Hello Tzafrir, native Debian applications are actually the ones which have the least benefit from this. I like a lot doc-central, because on computers with a short name, only a few keystrokes in the browser bar can call it. Switching from “foo/dc” to “foo/vendors-apps/dc” is unfun, expecially since the ‘-’ sign is a moving target on heterogeneous keyboard environments. Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
common, FHS-compliant, default document root for the various web servers
[ adding -policy to Cc: ]
On Wed, Nov 04, 2009 at 04:08:02PM +0100, Holger Levsen wrote:
Uhm, why postpone this so long? I'd hope we could find a consensus quite
soon.
Then, we might not be able to fix _all_ web apps until squeeze, but at least
tthose few with dir-or-file-in-var-www :-)
I see it a tad more complicate than you, let's hope its me
overestimating the task :-)
- the agreement actually should not come among web app maintainers, but
rather among web *server* maintainers: they should agree over a
specific dir and change the default configuration of the web server so
that that dir is the document root (for the default vhost, for web
servers supporting vhosts)
* possibly, migrating to that would require offering migration paths
to package users
- then you might start migrating web apps packages so that they install
(static) stuff under that dir, preserving the per-package path as
detailed in the webapps-common policy
- then, the rule should go into policy (possibly under §9.1.1, has an
exception to FHS, not sure about the section though) and that can't
happen before due to the usual practice-should-predate-policy
If it were me to try to achieve this, I would go for a DEP to keep track
of consensus, ... but no, I'm not willing to drive this, at least not
now :-)
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Re: common, FHS-compliant, default document root for the various web servers
Stefano Zacchiroli dijo [Wed, Nov 04, 2009 at 05:50:01PM +0100]: Uhm, why postpone this so long? I'd hope we could find a consensus quite soon. Then, we might not be able to fix _all_ web apps until squeeze, but at least tthose few with dir-or-file-in-var-www :-) I see it a tad more complicate than you, let's hope its me overestimating the task :-) - the agreement actually should not come among web app maintainers, but rather among web *server* maintainers: they should agree over a specific dir and change the default configuration of the web server so that that dir is the document root (for the default vhost, for web servers supporting vhosts) * possibly, migrating to that would require offering migration paths to package users That's easy, as there is fewer of us than web app maintainers. And it is a first step. We might even have a transitional symlink making /var/www point to /var/lib/www or whatnot? - then you might start migrating web apps packages so that they install (static) stuff under that dir, preserving the per-package path as detailed in the webapps-common policy - then, the rule should go into policy (possibly under §9.1.1, has an exception to FHS, not sure about the section though) and that can't happen before due to the usual practice-should-predate-policy If it were me to try to achieve this, I would go for a DEP to keep track of consensus, ... but no, I'm not willing to drive this, at least not now :-) It is a bit ambitious to have it _completely_ done by Squeeze. But we can start pushing the right way. And anyway, I do not feel it is asking too much. Yes, we cannot just go from using /var/www to having its existence violate policy and making insta-RC, but as soon as the (major at least) webserves change their defaults, we can start filing wishlist bugs, pointing maintainers to this being a work in progress and expecting it to be strictly enforced by policy for squeeze+1. -- Gunnar Wolf • gw...@gwolf.org • (+52-55)5623-0154 / 1451-2244 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
