|
Home > Archive > Unix administration > February 2004 > FHS History Lesson Desired
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
FHS History Lesson Desired
|
|
| Rob D. 2004-02-21, 12:33 pm |
| In the FHS standard (I'm looking at version 2.2), it states, "Large
software packages must not use a direct subdirectory under the /usr
hierarchy." Can anyone tell me the reasoning behind this?
I'm primarily concerned with whether the reason is technical or
traditional. On a large Unix system with many users, it's more
important to have binaries/libraries be in expected places, but on my
Linux from Scratch system (of which I'm the only user), it makes more
sense for packages to be arranged by what source tarball they came out
of, especially since I don't use (and am trying to avoid using) a
package manager. For example, it makes sense to me to put the inetutils
binaries and info/man pages under a directory like
/usr/tree/inetutils/inetutils-1.42 and use environment variables to get
at the documentation/binaries.
Using this method, I can keep things seperate and not suffer so badly
from not having a package manager, but I don't know the full
consequences of doing things this way. Symlinks in /bin and /usr/bin
take care of the scripting languages that expect interpreters to be in
those places, and there are still a number of packages that have hard
coded paths that can also be fixed with symlinks, but I don't have the
experience to know what else I might be breaking by doing things this way.
So, I finally come to the questions. What problems would I be creating
for myself by breaking the /usr (and probably /) directory structures up
by source packages and why does the FHS say not to do this?
| |
| Tim Skirvin 2004-02-22, 8:34 am |
| "Rob D." <nospam@example.net> writes:
>[...] on my Linux from Scratch system (of which I'm the only user), it
>makes more sense for packages to be arranged by what source tarball they
>came out of, especially since I don't use (and am trying to avoid using)
>a package manager.
What's wrong with using a package manager? Have you looked at the
managers like encap (http://www.encap.org/)? It appears that you're looking
to do by hand what encap already does very conveniently...
- Tim Skirvin (tskirvin@ks.uiuc.edu)
--
Theoretical and Computational http://www.ks.uiuc.edu/~tskirvin/
Biophysics, Beckman Institute, UIUC Senior Systems Administrator
| |
| Rob D. 2004-02-22, 9:34 am |
| Tim Skirvin wrote:
> "Rob D." <nospam@example.net> writes:
>
>
>
>
> What's wrong with using a package manager? Have you looked at the
> managers like encap (http://www.encap.org/)? It appears that you're looking
> to do by hand what encap already does very conveniently...
>
> - Tim Skirvin (tskirvin@ks.uiuc.edu)
Encap looks quite similar to what I wanted to do, but instead of having
so many symlinks I was going to use the PATH and other environment
variables to get at the package's files. I don't see how it saves a
whole lot of work over what I wanted to do, and it's probably more
beneficial to me from a learning standpoint to manipulate everything by
hand. My concern was over breaking something or violating some behavior
that would cause packages that I might need to be uninstallable in the
future.
|
|
|
|
|