[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', ]
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/',
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/',
/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/',
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...
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?
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.
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.
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
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 :)
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
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.
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?
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})
participants (7)
-
Alexander Rødseth
-
C Anthony Risinger
-
Ionut Biru
-
Jelle van der Waa
-
Pierre Schmitz
-
Seblu
-
Tom Gundersen