autoconf
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: FHS


From: Guido Draheim
Subject: Re: FHS
Date: Mon, 07 Jan 2002 00:47:47 +0100

Es schrieb Russ Allbery:
> 
> The vast majority of software installations by system administrators from
> source do not go into /usr, /etc, or anything else owned by the system.
> They go into /usr/local, /opt, or some other local path.  /usr and the
> like are reserved for the system and its own packaging system.

note that /opt is mentioned in FHS - most software layouts use it to
keep add-on packages seperate  - i.e. /opt/<package>/ (and IIRC it is
mentioned *that way* in FHS) but still they like the configfiles to
go to /etc... well... |^O

> [..]
> Personally, I'm somewhat annoyed to see yet more paths going into Autoconf
> that I'll then have to override to get the installation paths that I want
> (namely a flat tree of bin, sbin, lib, man, info, and etc); 

Personally, I have to put a lot of packages into my $home and I do not
quite like all the extra directories - I like to move *all* datalike
files to go to a /share/ path, esp. man and info-files. Moving pages
down feels good for me - and even more, in my mind, I have the abstraction
that most of the extra datafiles extend *another package*, that is my
own files go to $prefix/share/<package> and man-pages go to the share-
directory of the man-package and info-files go to the share-directory
of the info-package and aclocal-files go to the share-directory of the
aclocal tool. Moving the extra datafiles out of the share-tree does
violate this abstraction... just my 2 cent...

> 
> Changes towards stricter FHS compliance do make things harder for those of
> us who developed our file system layouts long before people started
> fiddling with things like share and libexec and don't want to go through
> the pain of trying to change them.
> 
and let me reiterate the fact that the FHS has not created a universal
prefix/subpaths scheme that the current default-prefix system in autoconf
has in use. And it might be better to keep with a simple install-layout
in basic autoconf - real soft admins will override them anyway to reflect
the needs of the local software policy.

/snip/
Another task is about a discussion of the current wealth of dirpaths that
we have in current autoconf - I do not quite remember how often I have
raised my voice in favour of a --doc-prefix so that at some point in the
future we can kill both mandir and infodir - it might be that future 
system installations will not anymore install info-pages (or even man-pages)
anymore, e.g. a desktop-centric system like darwin/mac. It might come the
time that info-files become obsolete and a thing of the past - IIRC, there
are projects underway to make docbook the help format of choice - but
there is no --docbookdir yet, and I fear the time we add yet another such
prefix for program help files where we could slay them all with one prefix
that a /man/ or /info/ or /help/ gets appended - soft admins will only
need to override the prefix to flatten the doc-filetree.

cheers,
-- guido                                    http://freespace.sf.net/guidod
GCS/E/S/P C++$++++ ULHS L++w- N++@ d(+-) s+a- r+@>+++ y++ 5++X- (geekcode)



reply via email to

[Prev in Thread] Current Thread [Next in Thread]