Status and outlook of LSB and FHS compliance of Fedora.

Doncho N. Gunchev mr700 at globalnet.bg
Fri Jun 4 08:11:53 UTC 2004


On Friday 04 June 2004 10:09, Marius Andreiana wrote:
> On Thu, 2004-06-03 at 18:53, Florian La Roche wrote:
> > > If all our customers in RHEL space start saying "but why not use /srv" during
> > > RHEL4 testing then maybe there is a case for change, otherwise its violating
> > > the first principle of engineering "If it aint broke..."
> yes!
> 
> > Right. I would hope that people who want to see the move happening to the /srv
> > layout also take some minutes and lobby for doing these changes. Until now
> > a see a huge majority who fears the change and does not believe in more
> > longterm benefits from this?
> yes. I don't see any benefits, only confusion:
> - exactly what services go in /srv? everything which is in /var now?
> - add another unclear partition (/srv) to decision making on
> partitioning
> - there are a lot of books/howtos which reference /var. Many people are
> migrating to linux now. They read those, find it's different in reality,
> confusing.
    Ah, why nobody reads release notes? They saved me so much time...
    /If nothing else works, read the manual :)/
> 

    What about *SLOW* migration (if it should happen)? FC3 could have /svr
with symlinks to the old /var locations and only some things like 
/var/www/{icons,error,manual} moved there (if moved at all) plus a release
note about this. The next FC4 could have everything migrated there and
symlinks in the old location and so on and so on... Maybe symlinks are
not the best choice, but many bind mounts (could solve some issues with
backup scripts) could make things a little bit messy?
    BTW: what is really supposed to remain in /var - only run, lib, lock,
log and tmp? Only files that the user should not touch and need or?

-- 
Regards,
  Doncho N. Gunchev    Registered Linux User #291323 at counter.li.org
  GPG-Key-ID: 1024D/DA454F79
  Key fingerprint = 684F 688B C508 C609 0371  5E0F A089 CB15 DA45 4F79





More information about the fedora-devel-list mailing list