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
chleuder 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 f
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,
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
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.
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 st
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
On Wed, 2018-02-28 at 18:14:17 -0500, Marvin Renich wrote:
> * Ian Jackson [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
er flag to let users
manage their own daemons.
On Thu, Mar 1, 2018 at 7:26 AM, Ian Jackson
wrote:
> Marvin Renich writes ("Re: FHS: Where to store user specific plugins / code"):
>> [stuff]
>
> I agree completely with Marvin's message.
>
> Ian.
>
Marvin Renich writes ("Re: FHS: Where to store user specific plugins / code"):
> [stuff]
I agree completely with Marvin's message.
Ian.
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, t
* Ian Jackson [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".
> >
> > Currentl
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 i
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,
Package: wnpp
Severity: wishlist
Owner: Nicolas Braud-Santoni
* 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
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
Guillem Jover 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
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 woul
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 concer
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
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 addi
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 sp
On Sun, Dec 18, 2011 at 03:37:43AM +0100, Marco d'Itri wrote:
> On Dec 17, Roger Leigh 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 an
On Dec 17, Roger Leigh 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 subo
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. Thi
On Dec 16, Roger Leigh 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
On Thu, Dec 15, 2011 at 06:19:54PM +0100, Marco d'Itri wrote:
> On Dec 15, Roger Leigh 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 thi
Roger Leigh 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 sele
Russ Allbery writes:
> Zachary Harris 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
>
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
Hi there!
On Thu, 15 Dec 2011 18:19:54 +0100, Marco d'Itri wrote:
> On Dec 15, Roger Leigh 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 thi
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 n
Thomas Goirand 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 ag
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
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.
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 alway
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
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 al
On Dec 15, Roger Leigh 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 p
r.
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,
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 cr
ach
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.
On Thu, Dec 15, 2011 at 01:57:20PM +0100, Marco d'Itri wrote:
> On Dec 15, Roger Leigh 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 issu
On Dec 15, Roger Leigh 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
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?
>
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 pr
ut 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
/li
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 t
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 woul
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
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 r
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 /
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
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
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 ti
Zachary Harris 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,
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
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 le
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 i
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,
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
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
> tha
7;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 requiri
Jan Hauke Rahm writes:
> On Mon, Nov 09, 2009 at 03:55:58PM -0800, Russ Allbery wrote:
>> sean finney 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 st
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 woul
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
> > >
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
lled.
given that there is likely a requirement for real world applications
to register themselves with a webserver anyway (for things which couldn't
"just work", extra Alias's for FHS splitting, etc), i don't see the
argument for making some subset of the package active when the
On Tue, Nov 10, 2009 at 4:29 PM, 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, t
t 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 poin
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 "wo
On Mon, Nov 09, 2009 at 03:55:58PM -0800, Russ Allbery wrote:
> sean finney 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 ensu
On Tue, Nov 10, 2009 at 6:50 AM, sean finney 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 com
sean finney 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 significa
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'
#x27;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
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
> ef
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
r.
> 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
ano,
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/ to /usr/share/www/:
- How many pur
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
> > >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
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 p
e
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 fi
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,
. 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
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 u
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.do
at 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 "va
I'm commenting a bit between the paragraphs to sharpen my mind :)
On Wed, Nov 04, 2009 at 08:09:18PM +0100, Stefano Zacchiroli wrote:
> What I was aiming to is a kind of document root which is under full
> control of the package manager; hence where the sysadm cannot touch
> anything by hand. That
On Wed, Nov 04, 2009 at 07:15:55PM +0100, Jan Hauke Rahm wrote:
> I don't get it. This would of course solve the problem of FHS compliance
> but apart from that it doesn't gain anything, does it?
> Now, do I totally misunderstand the issue here, or are we just moving
> the /v
rting 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/
-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
>
) 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-p
Theodore Tso writes ("Re: Is the FHS dead ?"):
> Well, the last time we tried to make reasonable accomodations for
> *BSD's, some of the biggest biggest whiners^H^H^H^H^H^H^H complaints
> came from Debian. In fact, some later complaints from Debianites
> about the lack
largely the fault of Ian Jackson,
> who ***strenuously*** opposed /usr/libexec on the mail thread which I
> quoted. In fact, as I recall, he threatened to rally all of Debian
> NOT to support the FSSTND/FHS if we didn't drop /usr/libexec from the
> draft spec. Ah, history.....
On Fri, Feb 27, 2009 at 12:44 AM, Giacomo A. Catenazzi wrote:
> Russ Allbery wrote:
>>
>> Luke L writes:
>>
>>> Something to think about: Shouldn't SQL databases and web servers, and
>>> file servers, be under /srv/? /srv/www, /srv/mysql, /srv/smb,
Russ Allbery wrote:
Luke L writes:
Something to think about: Shouldn't SQL databases and web servers, and
file servers, be under /srv/? /srv/www, /srv/mysql, /srv/smb, etc.?
The current FHS reserves /srv's namespace for the local administrator. My
guess is that people won't
Giacomo Catenazzi writes:
> Standards should be most frozen as possible. I don't find a lot of
> think that need to be added.
What about cross compile and multiarch paths?
The old lib32/lib64 dirs currently mentioned in the FHS are just not
covering enough cases and are misleading
Luke L writes:
> Something to think about: Shouldn't SQL databases and web servers, and
> file servers, be under /srv/? /srv/www, /srv/mysql, /srv/smb, etc.?
The current FHS reserves /srv's namespace for the local administrator. My
guess is that people won't want to go bac
1 - 100 of 338 matches
Mail list logo
