Accepted python-fhs 1.2-1 (source) into unstable

2023-02-18 Thread Debian FTP Masters
-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

2022-10-24 Thread Debian FTP Masters
-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

2022-10-09 Thread Debian FTP Masters
-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

2022-10-07 Thread Debian FTP Masters
-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

2022-05-31 Thread Debian FTP Masters
-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

2022-05-15 Thread Debian FTP Masters
-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.

2022-04-22 Thread Bas Wijnen
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

2021-02-06 Thread Debian FTP Masters
-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

2021-01-09 Thread Debian FTP Masters
-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

2019-02-12 Thread Nicolas Braud-Santoni
-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

2019-02-03 Thread Clint Adams
-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

2018-03-09 Thread Georg Faerber
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

2018-03-09 Thread Enrico Weigelt, metux IT consult

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

2018-03-09 Thread Jonas Meurer
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

2018-03-09 Thread Georg Faerber
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

2018-03-09 Thread Georg Faerber
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

2018-03-09 Thread Georg Faerber
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

2018-03-01 Thread Guillem Jover
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

2018-03-01 Thread Peter Silva
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

2018-03-01 Thread Ian Jackson
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

2018-02-28 Thread Weldon
 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

2018-02-28 Thread Marvin Renich
* 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

2018-02-28 Thread Ian Jackson
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

2018-02-28 Thread Georg Faerber
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

2018-01-16 Thread Nicolas Braud-Santoni
-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.

2016-05-05 Thread Nicolas Braud-Santoni
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

2012-01-08 Thread Steve Langasek
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

2011-12-22 Thread Goswin von Brederlow
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

2011-12-21 Thread Guillem Jover
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

2011-12-20 Thread J.A. Bezemer


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

2011-12-20 Thread Roger Leigh
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

2011-12-19 Thread Roger Leigh
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

2011-12-19 Thread J.A. Bezemer


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

2011-12-19 Thread Roger Leigh
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

2011-12-17 Thread Roger Leigh
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

2011-12-17 Thread Marco d'Itri
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

2011-12-16 Thread Goswin von Brederlow
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

2011-12-16 Thread Goswin von Brederlow
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

2011-12-16 Thread Roger Leigh
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

2011-12-16 Thread Marco d'Itri
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

2011-12-15 Thread Roger Leigh
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

2011-12-15 Thread Roger Leigh
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

2011-12-15 Thread Marco d'Itri
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

2011-12-15 Thread Roger Leigh
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

2011-12-15 Thread Zachary Harris
  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

2011-12-15 Thread Simon McVittie
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

2011-12-15 Thread Riku Voipio
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

2011-12-15 Thread Marco d'Itri
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

2011-12-15 Thread Roger Leigh
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

2011-12-15 Thread Joey Hess
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

2011-12-15 Thread Thomas Goirand
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

2011-12-15 Thread Thomas Goirand
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

2011-12-15 Thread Josselin Mouette
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

2011-12-15 Thread Russ Allbery
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

2011-12-15 Thread Michael Biebl
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

2011-12-15 Thread Luca Capello
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

2011-12-15 Thread Roger Leigh
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

2011-12-14 Thread Ian Jackson
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

2011-12-14 Thread Zachary Harris

  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

2011-12-14 Thread Roger Leigh
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

2011-12-14 Thread Jonathan Nieder
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

2011-12-14 Thread Jonathan Nieder
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

2011-12-14 Thread J.A. Bezemer


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

2011-12-14 Thread Michael Biebl
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

2011-12-14 Thread Michael Biebl
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

2011-12-14 Thread Zachary Harris
 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

2011-12-13 Thread Zachary Harris
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

2011-12-13 Thread Russ Allbery
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

2010-07-16 Thread Mike Hommey
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

2010-07-16 Thread Alexander Reichle-Schmehl
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

2010-07-16 Thread Christoph Anton Mitterer
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

2009-11-20 Thread Stefano Zacchiroli
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

2009-11-15 Thread sean finney
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

2009-11-13 Thread Stefano Zacchiroli
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

2009-11-10 Thread Jan Hauke Rahm
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

2009-11-10 Thread Jan Hauke Rahm
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

2009-11-10 Thread sean finney
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

2009-11-10 Thread Stefan Fritsch
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

2009-11-10 Thread Stefan Fritsch
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

2009-11-10 Thread Neil McGovern
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

2009-11-10 Thread Russ Allbery
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

2009-11-09 Thread Stefano Zacchiroli
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

2009-11-09 Thread Stefano Zacchiroli
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

2009-11-09 Thread Stefano Zacchiroli
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

2009-11-09 Thread Charles Plessy
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

2009-11-09 Thread Jan Hauke Rahm
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

2009-11-09 Thread Jan Hauke Rahm
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

2009-11-09 Thread Stefano Zacchiroli
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

2009-11-09 Thread sean finney
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

2009-11-09 Thread sean finney
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

2009-11-09 Thread Russ Allbery
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

2009-11-09 Thread Paul Wise
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

2009-11-08 Thread Henrik Andreasson

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

2009-11-07 Thread Jan Hauke Rahm
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

2009-11-07 Thread Charles Plessy
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

2009-11-07 Thread Tzafrir Cohen
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

2009-11-07 Thread Jan Hauke Rahm
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

2009-11-07 Thread Charles Plessy
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

2009-11-04 Thread Stefano Zacchiroli
[ 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

2009-11-04 Thread Gunnar Wolf
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



  1   2   3   4   >