[arch-projects] [PATCH 1/4] fhs: remove /var/lock form valid paths
It is already forbidden, so should not be valid. Signed-off-by: Tom Gundersen <teg@jklm.no> --- Namcap/rules/fhs.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Namcap/rules/fhs.py b/Namcap/rules/fhs.py index 2ce34d0..28cb30f 100644 --- a/Namcap/rules/fhs.py +++ b/Namcap/rules/fhs.py @@ -29,7 +29,7 @@ class FHSRule(TarballRule): 'bin/', 'etc/', 'lib/', 'sbin/', 'opt/', 'srv/', 'usr/bin/', 'usr/include/', 'usr/lib/', 'usr/lib32/', 'usr/sbin/', 'usr/share/', - 'var/cache/', 'var/lib/', 'var/lock/', 'var/log/', 'var/opt/', + 'var/cache/', 'var/lib/', 'var/log/', 'var/opt/', 'var/spool/', 'var/state/', '.PKGINFO', '.INSTALL', '.CHANGELOG', ] -- 1.7.9.2
We want to empty /lib over time. This explicitly allows the subdirs that we don't yet have a plan for emptying, and disallows everything else. This will in particular throw warnings for /lib/*.so* and for /lib/systemd/*. The former is intentional, and the latter can be moved to /usr/lib/systemd (upstream supports some stuff in /usr/lib and some in /lib, so no need for a flag day). We might want to explicitly allow the linker, but I conjecture that Allan will not be intimidated by a namcap warning into moving it, so we should be safe. Signed-off-by: Tom Gundersen <teg@jklm.no> --- Namcap/rules/fhs.py | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Namcap/rules/fhs.py b/Namcap/rules/fhs.py index 28cb30f..3c1d599 100644 --- a/Namcap/rules/fhs.py +++ b/Namcap/rules/fhs.py @@ -26,7 +26,9 @@ class FHSRule(TarballRule): description = "Checks for standard directories." def analyze(self, pkginfo, tar): valid_paths = [ - 'bin/', 'etc/', 'lib/', 'sbin/', 'opt/', 'srv/', + 'bin/', 'etc/', 'opt/', 'sbin/', 'srv/', + 'lib/depmod.d', 'lib/firmware', 'lib/initcpio', + 'lib/modprobe.d', 'lib/modules', 'lib/security', 'lib/udev', 'usr/bin/', 'usr/include/', 'usr/lib/', 'usr/lib32/', 'usr/sbin/', 'usr/share/', 'var/cache/', 'var/lib/', 'var/log/', 'var/opt/', -- 1.7.9.2
To the extent possible these dirs should be emptied and moved to /usr/bin. In particular we want to avoid new or third-party packages putting stuff here. Some things need to stay in the root (coreutils, util-linux, bash, mount-helpers, ...), but we'll rely on the relevant packagers knowing this and ignoring the warnings. Signed-off-by: Tom Gundersen <teg@jklm.no> --- Namcap/rules/fhs.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Namcap/rules/fhs.py b/Namcap/rules/fhs.py index 3c1d599..09180f6 100644 --- a/Namcap/rules/fhs.py +++ b/Namcap/rules/fhs.py @@ -26,7 +26,7 @@ class FHSRule(TarballRule): description = "Checks for standard directories." def analyze(self, pkginfo, tar): valid_paths = [ - 'bin/', 'etc/', 'opt/', 'sbin/', 'srv/', + 'etc/', 'opt/', 'srv/', 'lib/depmod.d', 'lib/firmware', 'lib/initcpio', 'lib/modprobe.d', 'lib/modules', 'lib/security', 'lib/udev', 'usr/bin/', 'usr/include/', 'usr/lib/', 'usr/lib32/', -- 1.7.9.2
/srv is admin territory, similar to /home. No package should put stuff there. The filesystem package does install /srv/ftp and /srv/http, but that's my problem to worry about (and namcap can't deal with the filesystem package anyway). Signed-off-by: Tom Gundersen <teg@jklm.no> --- Namcap/rules/fhs.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Namcap/rules/fhs.py b/Namcap/rules/fhs.py index 09180f6..9f555fa 100644 --- a/Namcap/rules/fhs.py +++ b/Namcap/rules/fhs.py @@ -26,7 +26,7 @@ class FHSRule(TarballRule): description = "Checks for standard directories." def analyze(self, pkginfo, tar): valid_paths = [ - 'etc/', 'opt/', 'srv/', + 'etc/', 'opt/', 'lib/depmod.d', 'lib/firmware', 'lib/initcpio', 'lib/modprobe.d', 'lib/modules', 'lib/security', 'lib/udev', 'usr/bin/', 'usr/include/', 'usr/lib/', 'usr/lib32/', -- 1.7.9.2
On Sun, Feb 26, 2012 at 2:56 PM, Tom Gundersen <teg@jklm.no> wrote:
/srv is admin territory, similar to /home. No package should put stuff there. Are you sure of this? Currently many "http" packages use /srv/http to put static files. e.g backuppc, flyspray, roundcube...
http://www.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYS... -- Sébastien Luttringer www.seblu.net
Where should WordPress put the files if not in /srv/http? In /usr/lib/wordpress, with a script that copies the relevant files into /srv/http? -- Cordially, Alexander Rødseth Arch Linux Trusted User (xyproto on IRC, trontonic on AUR)
On 02/26/2012 05:11 PM, Alexander Rødseth wrote:
Where should WordPress put the files if not in /srv/http? In /usr/lib/wordpress, with a script that copies the relevant files into /srv/http?
/usr/share/webapps if i recall, phpmyadmin is packaged correctly. -- Ionuț
Am 26.02.2012 16:18, schrieb Ionut Biru:
On 02/26/2012 05:11 PM, Alexander Rødseth wrote:
Where should WordPress put the files if not in /srv/http? In /usr/lib/wordpress, with a script that copies the relevant files into /srv/http?
/usr/share/webapps
if i recall, phpmyadmin is packaged correctly.
Doesn't look correct to me. It should be in /usr/share/phpmyadmin. That webapps subdir is stupid. -- Pierre Schmitz, http://pierre-schmitz.com
If all packages should install into /usr/share instead of /srv, how about a TODO? I can create it if there is consensus that it's a good idea. - Alexander
On Mon, Feb 27, 2012 at 6:48 PM, Alexander Rødseth <rodseth@gmail.com> wrote:
If all packages should install into /usr/share instead of /srv, how about a TODO? I can create it if there is consensus that it's a good idea. This should be great !
I see this old wiki page: https://wiki.archlinux.org/index.php/Web_application_package_guidelines -- Sébastien Luttringer www.seblu.net
On Sun, Feb 26, 2012 at 3:46 PM, Seblu <seblu@seblu.net> wrote:
On Sun, Feb 26, 2012 at 2:56 PM, Tom Gundersen <teg@jklm.no> wrote:
/srv is admin territory, similar to /home. No package should put stuff there. Are you sure of this? Currently many "http" packages use /srv/http to put static files. e.g backuppc, flyspray, roundcube...
http://www.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYS...
The consensus seems to be that we don't let packages put stuff in /srv, so I thought it would make sense to let namcap reflect this. Though one should keep in mind that namcap can be ignored if you must and you know what you are doing. This was discussed before, see [0] for an example. Cheers, Tom [0] http://mailman.archlinux.org/pipermail/arch-general/2009-October/007800.html
On Sun, Feb 26, 2012 at 4:20 PM, Tom Gundersen <teg@jklm.no> wrote:
On Sun, Feb 26, 2012 at 3:46 PM, Seblu <seblu@seblu.net> wrote:
On Sun, Feb 26, 2012 at 2:56 PM, Tom Gundersen <teg@jklm.no> wrote:
/srv is admin territory, similar to /home. No package should put stuff there. Are you sure of this? Currently many "http" packages use /srv/http to put static files. e.g backuppc, flyspray, roundcube...
http://www.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYS...
The consensus seems to be that we don't let packages put stuff in /srv, so I thought it would make sense to let namcap reflect this. Sure !
I just wondering what is the arch way of doing web package :) -- Sébastien Luttringer www.seblu.net
On Tue, Feb 28, 2012 at 3:34 PM, Seblu <seblu@seblu.net> wrote:
On Sun, Feb 26, 2012 at 4:20 PM, Tom Gundersen <teg@jklm.no> wrote:
On Sun, Feb 26, 2012 at 3:46 PM, Seblu <seblu@seblu.net> wrote:
On Sun, Feb 26, 2012 at 2:56 PM, Tom Gundersen <teg@jklm.no> wrote:
/srv is admin territory, similar to /home. No package should put stuff there. Are you sure of this? Currently many "http" packages use /srv/http to put static files. e.g backuppc, flyspray, roundcube...
http://www.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYS...
The consensus seems to be that we don't let packages put stuff in /srv, so I thought it would make sense to let namcap reflect this. Sure !
I just wondering what is the arch way of doing web package :)
-- Sébastien Luttringer www.seblu.net
Take a look out phpmyadmin -- Jelle van der Waa
On Tue, Feb 28, 2012 at 3:51 PM, Jelle van der Waa <jelle@vdwaa.nl> wrote:
On Tue, Feb 28, 2012 at 3:34 PM, Seblu <seblu@seblu.net> wrote:
On Sun, Feb 26, 2012 at 4:20 PM, Tom Gundersen <teg@jklm.no> wrote:
On Sun, Feb 26, 2012 at 3:46 PM, Seblu <seblu@seblu.net> wrote:
On Sun, Feb 26, 2012 at 2:56 PM, Tom Gundersen <teg@jklm.no> wrote:
/srv is admin territory, similar to /home. No package should put stuff there. Are you sure of this? Currently many "http" packages use /srv/http to put static files. e.g backuppc, flyspray, roundcube...
http://www.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYS...
The consensus seems to be that we don't let packages put stuff in /srv, so I thought it would make sense to let namcap reflect this. Sure !
I just wondering what is the arch way of doing web package :)
what's about adding /etc/webapps and /usr/share/webapps in php.ini ? We already add /srv/http.
-- Sébastien Luttringer www.seblu.net
On Tue, Feb 28, 2012 at 5:59 PM, Seblu <seblu@seblu.net> wrote:
On Tue, Feb 28, 2012 at 3:51 PM, Jelle van der Waa <jelle@vdwaa.nl> wrote:
On Tue, Feb 28, 2012 at 3:34 PM, Seblu <seblu@seblu.net> wrote:
On Sun, Feb 26, 2012 at 4:20 PM, Tom Gundersen <teg@jklm.no> wrote:
On Sun, Feb 26, 2012 at 3:46 PM, Seblu <seblu@seblu.net> wrote:
On Sun, Feb 26, 2012 at 2:56 PM, Tom Gundersen <teg@jklm.no> wrote:
/srv is admin territory, similar to /home. No package should put stuff there. Are you sure of this? Currently many "http" packages use /srv/http to put static files. e.g backuppc, flyspray, roundcube...
http://www.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYS...
The consensus seems to be that we don't let packages put stuff in /srv, so I thought it would make sense to let namcap reflect this. Sure !
I just wondering what is the arch way of doing web package :)
what's about adding /etc/webapps and /usr/share/webapps in php.ini ? We already add /srv/http.
Looking inside repositories for examples, phpmyadmin look like an exception. We lack of clean rules and a cleanning of our web packages. What's about a /var/lib/webapps to have "writable" content outside /usr ? Wiki suggest to symlink /var/lib to /usr/share/webapps? -- Sébastien Luttringer www.seblu.net
On Tue, Feb 28, 2012 at 11:08 AM, Seblu <seblu@seblu.net> wrote:
On Tue, Feb 28, 2012 at 5:59 PM, Seblu <seblu@seblu.net> wrote:
what's about adding /etc/webapps and /usr/share/webapps in php.ini ? We already add /srv/http.
Looking inside repositories for examples, phpmyadmin look like an exception. We lack of clean rules and a cleanning of our web packages.
What's about a /var/lib/webapps to have "writable" content outside /usr ? Wiki suggest to symlink /var/lib to /usr/share/webapps?
imo, which is the only relevant opinion [sarcasm], these things should be in /usr/share/{pkgname} like anything else, with upload directories/etc configured to /var/lib/{pkgname}. phpmyadmin (on debian?) IIRC works like this -- nothing should be writing to /etc, and preferably nothing should be writing to /usr/share either (locale-gen is the only tool i know off-hand that does this regularly, and is incorrect imo). on other distros these webapps are enabled by dropping configuration files in /etc/httpd/* ... it would be nice to have a generic way of specifying installation details (vs. just assuming apache2, which bytes compared to uwsgi/mongrel2/nginx/{insert-here}) -- C Anthony
participants (7)
-
Alexander Rødseth
-
C Anthony Risinger
-
Ionut Biru
-
Jelle van der Waa
-
Pierre Schmitz
-
Seblu
-
Tom Gundersen