Status and outlook of LSB and FHS compliance of Fedora.

Chris Chabot chabotc at 4-ice.com
Thu Jun 3 11:29:21 UTC 2004


Please let me begin by comming out and admitting that this whole /svr *edit*
seems quite silly to me.

The reasoning behind /svr is described in FHS-2.3 as: "This main purpose of
specifying this is so that users may find the location of the data files for
particular service and so that services which require a single tree for
readonly data, writable data and scripts (such as cgi scripts) can be
reasonably placed". in other words, from what my somewhat limited
understanding is, it is so that users can "find service related data (such
as cvs tree's, html files, etc)" and that automated scripts can do the same.

To then add confusion to unclarity it continues to read "The methodology
used to name subdirectories of /srv is unspecified as there is currently no
consensus on how this should be done"

Now i applaud efforts that aim to make Unix more understandable, however i
do not see every old *nix instalation rebuilding its file structure, nor do
i forsee a quick adoptation of this file heirarchy dependency in external
scripts, and i also do not see old *nix admins and developers easely
adopting to this new layout.

That being said, there's no reason for Fedora not trying to be the teachers
favorite, and providing this /svr solution.. However please then do it by
placing some stratigicly chosen symlinks (ln -s /var/www/html /svr/www) and
leaving the existing data layout as it is. That way Fedora could claim
conformaty to the new standards, while not upsetting the current situation.

The only package i would like to nominate for some serious relocation of
it's files would be mailman .. It's got it's own little world going on in
/var/lib/mailman, with files that should really be located in /usr/bin (add,
list_members, change_pw, check_db, etc) and /usr/libexec (qrunner) ..
Preferably with binaries renamed to something less generic as 'list_members'
(but instead mailman_list_members?).. But that's a whole 'nother gripe, and
not really related to the /svr discussion (though somewhat related since
it's a clear example of a non transparent and constent file layout and
naming)

Anyhow, thats my 2 euro cents... Which from what my news feed tells me, is
nowadays worth more then 2 US cents! :-)

    -- Chris

----- Original Message ----- 
From: "Phil Knirsch" <pknirsch at redhat.com>
To: "Development discussions related to Fedora Core"
<fedora-devel-list at redhat.com>
Sent: Thursday, June 03, 2004 11:25
Subject: Status and outlook of LSB and FHS compliance of Fedora.


> Hi folks.
>
> I've been looking at how well Fedora is compliant with the latest LSB
> and FHS specifications lately.
>
> I came up with a small list of packages that, due to the change in the
> latest FHS-2.3 and the addition of /srv and /media would seem likely
> candidates for partiall data migration to /srv:
>
> bind
> arpwatch
> mailman
> krb5-server
> httpd
> tomcat
> htdig
> openldap
> mysql
> namazu
> inn
> postgresql
> webalizer
> vsftpd
>
> Quite a few of those packages could keep their data in /var as their are
> either minor packages or uncritical in general.
>
> Only bind, httpd and vsftpd are the really imporant packages with lots
> of data. Bind will stay where it is mainly for historical reasons as
> everyone excpects /var/named to exist and contain all the important bind
> configuration and data.
>
> That only leaves vsftpd and httpd. The problem with those packages is
> how to ensure and guarantee a 100% safe data migration of data during an
> upgrade. For that reason we probably will keep them where they are for
> now, too. For httpd it would also probably brake quite a few 3rd party
> applications that either directly write to /var/www/html or which do
> some other work with /var/www and expect it to be there as currently.
>
> So mainly for historical and data migration reasons we have decided to
> only provide /media and /srv for FHS-2.3 compliant applications in the
> near future but won't move any of the existing package data there for now.
>
> Hope this explains a little our reasoning and motivations related to and
> concerning the LSB/FHS and where we stand and want to go in the future.
>
> Any comments/concerns/ideas/flamewars are, as always very welcome. :-)
>
> Read ya, Phil
>
> -- 
> Philipp Knirsch      | Tel.:  +49-711-96437-470
> Development          | Fax.:  +49-711-96437-111
> Red Hat GmbH         | Email: Phil Knirsch <phil at redhat.de>
> Hauptstaetterstr. 58 | Web:   http://www.redhat.de/
> D-70178 Stuttgart
> Motd:  You're only jealous cos the little penguins are talking to me.
>
>
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-devel-list
>





More information about the fedora-devel-list mailing list