sourcenav deb dir layout

sourcenav deb dir layout

[Eray 'exa' Ozkural]

The following is the dir layout of sourcenav package:

There are several problems with it. It doesn't seem to comply with
FHS or GNU coding standards. I can fix some of it, but ultimately
you should decide how it will play nicely with a system.
What is your opinion?

-- usr
    |-- bin
    |-- html
    |   |-- progref
    |   `-- userguide
    |-- lib
    |-- sbin
    `-- share
        |-- bitmaps
        |-- demos
        |-- doc
        |   `-- sourcenav
        |-- etc
        |-- gui
        `-- sdk
            |-- api
            |   |-- c
            |   |   `-- database
            |   |       `-- examples
            |   `-- tcl
            |       |-- database
            |       |   `-- examples
            |       `-- misc
            |-- include
            |-- lib
            `-- parsers
                `-- examples
                    |-- assembly
                    `-- elf

Re: sourcenav deb dir layout

[Syd Polk]

At 07:36 PM 10/17/00 +0300, Eray 'exa' Ozkural wrote:
>The following is the dir layout of sourcenav package:
>
>There are several problems with it. It doesn't seem to comply with
>FHS or GNU coding standards. I can fix some of it, but ultimately
>you should decide how it will play nicely with a system.
>What is your opinion?

First of all, this project was never written to the FHS or GNU coding 
standards. Our official coding standards are the Tcl coding standards. This 
is for all new code. The original code was never written to a standard; we 
are slowly fixing that.

Secondly, what changes are you proposing?

>-- usr
>     |-- bin
>     |-- html
>     |   |-- progref
>     |   `-- userguide
>     |-- lib
>     |-- sbin
>     `-- share
>         |-- bitmaps
>         |-- demos
>         |-- doc
>         |   `-- sourcenav
>         |-- etc
>         |-- gui
>         `-- sdk
>             |-- api
>             |   |-- c
>             |   |   `-- database
>             |   |       `-- examples
>             |   `-- tcl
>             |       |-- database
>             |       |   `-- examples
>             |       `-- misc
>             |-- include
>             |-- lib
>             `-- parsers
>                 `-- examples
>                     |-- assembly
>                     `-- elf
>
>

Syd Polk		spolk@redhat.com
Engineering Manager	+1 415 777 9810 x 241
Red Hat, Inc.

Re: sourcenav deb dir layout

[Eray Ozkural]

Syd Polk wrote:
> 
> First of all, this project was never written to the FHS or GNU coding
> standards. Our official coding standards are the Tcl coding standards. This
> is for all new code. The original code was never written to a standard; we
> are slowly fixing that.
> 

Excuse my ignorance, I'm not aware of tcl coding standards. Does it
indicate where you should be putting docs or binary data?

> Secondly, what changes are you proposing?
> 

First, all doc files go to their debian doc dir /usr/share/doc/sourcenav.
that doesn't concern you much I guess.

demos also go to doc dir.

share/bitmaps, share/gui  -> share/sourcenav/

i don't know where to put sdk, since sdk is not specific to sourcenav?
if it is specific to sourcenav, then it also goes under share/sourcenav
it looks like read only arch-independent data.

Cheers,

> >-- usr
> >     |-- bin
> >     |-- html
> >     |   |-- progref
> >     |   `-- userguide
> >     |-- lib
> >     |-- sbin
> >     `-- share
> >         |-- bitmaps
> >         |-- demos
> >         |-- doc
> >         |   `-- sourcenav
> >         |-- etc
> >         |-- gui
> >         `-- sdk
> >             |-- api
> >             |   |-- c
> >             |   |   `-- database
> >             |   |       `-- examples
> >             |   `-- tcl
> >             |       |-- database
> >             |       |   `-- examples
> >             |       `-- misc
> >             |-- include
> >             |-- lib
> >             `-- parsers
> >                 `-- examples
> >                     |-- assembly
> >                     `-- elf
> >
> >

-- 
Eray (exa) Ozkural
Comp. Sci. Dept., Bilkent University, Ankara
e-mail: erayo@cs.bilkent.edu.tr
www: http://www.cs.bilkent.edu.tr/~erayo

Re: sourcenav deb dir layout

[Syd Polk]

At 03:02 AM 10/18/00 +0300, Eray Ozkural wrote:
>Syd Polk wrote:
> >
> > First of all, this project was never written to the FHS or GNU coding
> > standards. Our official coding standards are the Tcl coding standards. This
> > is for all new code. The original code was never written to a standard; we
> > are slowly fixing that.
> >
>
>Excuse my ignorance, I'm not aware of tcl coding standards. Does it
>indicate where you should be putting docs or binary data?

Tcl coding standards do not specify the layout of packages.


> > Secondly, what changes are you proposing?
> >
>
>First, all doc files go to their debian doc dir /usr/share/doc/sourcenav.
>that doesn't concern you much I guess.
>
>demos also go to doc dir.
>
>share/bitmaps, share/gui  -> share/sourcenav/
>
>i don't know where to put sdk, since sdk is not specific to sourcenav?
>if it is specific to sourcenav, then it also goes under share/sourcenav
>it looks like read only arch-independent data.
>
>Cheers,

Source-Navigator is designed to integrated with the other gnu tools that 
Red Hat offers, and has a directory structure which maps that. We will keep 
these changes in mind, however.


Syd Polk		spolk@redhat.com
Engineering Manager	+1 415 777 9810 x 241
Red Hat, Inc.

Re: sourcenav deb dir layout

[Mike A. Harris]

On Tue, 17 Oct 2000, Eray 'exa' Ozkural wrote:

>Date: Tue, 17 Oct 2000 19:36:36 +0300 (EEST)
>From: Eray 'exa' Ozkural <erayo@cs.bilkent.edu.tr>
>To: sourcenav@sources.redhat.com
>Content-Type: TEXT/PLAIN; charset=US-ASCII
>Subject: sourcenav deb dir layout
>
>The following is the dir layout of sourcenav package:
>
>There are several problems with it. It doesn't seem to comply with
>FHS or GNU coding standards. I can fix some of it, but ultimately
>you should decide how it will play nicely with a system.
>What is your opinion?
>
>-- usr
>    |-- bin
>    |-- html
>    |   |-- progref
>    |   `-- userguide
          ^^^^^^^^^^^^

I don't like those 2 dirs.  They bind "progref, userguide" to
sourcenav, however 40 packages could have dirs named
"userguide".  Perhaps:

 html
 |
 ----sourcenav
     |
     ----progref
     ----userguide

No ambiguity then.  Actually, /usr/share/html would be a better
place IMHO, but....  ;o)

TTYL


----------------------------------------------------------------------
      Mike A. Harris  -  Linux advocate  -  Open source advocate
              Computer Consultant - Capslock Consulting
                 Copyright 2000 all rights reserved
----------------------------------------------------------------------

If you're looking for Linux books, guides, and other documentation, visit 
the Linux Documentation Project homepage:  http://linuxdoc.org

Re: sourcenav deb dir layout

[Mike A. Harris]

On Tue, 17 Oct 2000, Syd Polk wrote:

>>i don't know where to put sdk, since sdk is not specific to sourcenav?
>>if it is specific to sourcenav, then it also goes under share/sourcenav
>>it looks like read only arch-independent data.
>>
>>Cheers,
>
>Source-Navigator is designed to integrated with the other gnu tools that 
>Red Hat offers, and has a directory structure which maps that. We will keep 
>these changes in mind, however.

The funny thing though, is Source Navigator doesn't follow Red
Hat conventions of file locations either.  ;o)  Red Hat 7.0 of
course approaches FHS compliance, and both debian and Red Hat are
becoming similar in this manner.

The reason I'm pointing this out is because I am trying to
package Source Navigator for Red Hat right now, and having
similar difficulties.  ;o)  The default install of a source nav
build scatters files in odd locations as I found out the hard
way..  ;o)  I had it build for /usr/local, and after installing
had numerous problems as an ordinary user on my system.  Root,
everything worked fine, but as a user, I had different problems
running scripts, etc..

It turns out, source nav installs grep/egrep/fgrep and a slew of
other utils into /usr/local/bin when built for /usr/local, and
/usr/local was in the path first, so the sourcenav utils got used
instead of /bin/grep, etc..  The problem is that the SourceNav
grep and friends do not support all grep commandline options.  It
took me a few days to figure this out..  ;o)

What is the reasoning behind bringing a copy of grep and other
utils with sourcenav? Is it for systems not having it?  If so,
can I safely exclude it from the Red Hat packages?

To the fellow creating the deb packages, could you post your deb
build files, (not the packages, just the deb equiv of .spec
files) to me privately.  I'll share my .spec with you as well if
you like.

Perhaps we could take some of the changes that will be necessary
in the build sections of our efforts and incorporate them
directly into the Sourcenav makefiles, etc. and send patches in?

Well, one thing at a time I suppose.  ;o)

Take care everyone!
TTYL

----------------------------------------------------------------------
      Mike A. Harris  -  Linux advocate  -  Open source advocate
              Computer Consultant - Capslock Consulting
                 Copyright 2000 all rights reserved
----------------------------------------------------------------------

"If it isn't source, it isn't software."  -- NASA

Re: sourcenav deb dir layout

[Ben Elliston]

   What is the reasoning behind bringing a copy of grep and other utils
   with sourcenav? Is it for systems not having it?  If so, can I safely
   exclude it from the Red Hat packages?

The version of grep that is built by S-N includes a number of command line
options that were necessary to make it work better with S-N -- for instance,
it emitted progress indication to stderr which S-N used to give visual
feedback of grep's progress.

I believe the current version eliminates the need for a special version of
grep, but I could be mistaken.  I'll leave that up to one of the current
team to speak about.

Ben

Re: sourcenav deb dir layout

[Mo DeJong]

On Wed, 18 Oct 2000, Ben Elliston wrote:

>    What is the reasoning behind bringing a copy of grep and other utils
>    with sourcenav? Is it for systems not having it?  If so, can I safely
>    exclude it from the Red Hat packages?
> 
> The version of grep that is built by S-N includes a number of command line
> options that were necessary to make it work better with S-N -- for instance,
> it emitted progress indication to stderr which S-N used to give visual
> feedback of grep's progress.
> 
> I believe the current version eliminates the need for a special version of
> grep, but I could be mistaken.  I'll leave that up to one of the current
> team to speak about.
> 
> Ben

Guys, I thought we had been over this before. Yes, 4.5
uses a custom grep that was forked a couple of years
ago. The need for this custom grep has been removed
in 5.0 because of all the problems it would create if
you tried to make a RPM.

I still think it is great that you gents are willing to
go through the pain of creating deb/rpm package for
4.5, but I still think you should just put everything
in a sn root (like /usr/sourcenav) and be done
with it. You are going to have nothing but problems
trying to get the 4.5 codebase to play nice with
the other executables in /usr.

Toasted executables:

egrep
fgrep
grep
itclsh3.0
itkwish3.0
tclsh
wish

Heck, just the fact that you dont want to
install /usr/README.TXT is enough.

Mo DeJong
Red Hat Inc

Re: sourcenav deb dir layout

[Mike A. Harris]

On Wed, 18 Oct 2000, Ben Elliston wrote:

>   What is the reasoning behind bringing a copy of grep and other utils
>   with sourcenav? Is it for systems not having it?  If so, can I safely
>   exclude it from the Red Hat packages?
>
>The version of grep that is built by S-N includes a number of command line
>options that were necessary to make it work better with S-N -- for instance,
>it emitted progress indication to stderr which S-N used to give visual
>feedback of grep's progress.
>
>I believe the current version eliminates the need for a special version of
>grep, but I could be mistaken.  I'll leave that up to one of the current
>team to speak about.

When a specific program or util MUST use it's own local copy of a
standard system tool, it should rename it to avoid problems.  In
other words, Source Nav's "grep" should be renamed: sn-grep or
something similar.

It broke many system scripts I have, and caused several days of
"WTH is going on?" questions..  ;o)

You never know how a user's path is going to look.  Programs like
xcdroast used to include cdrecord, mkisofs, etc.. and called them
"mycdrecord", "mymkisofs" to avoid conflict.  It also put them in
its own private dir not in the path.

Just some suggestions...

Take care all.
TTYL


----------------------------------------------------------------------
      Mike A. Harris  -  Linux advocate  -  Open source advocate
              Computer Consultant - Capslock Consulting
                 Copyright 2000 all rights reserved
----------------------------------------------------------------------


If you're looking for Linux books, guides, and other documentation, visit 
the Linux Documentation Project homepage:  http://linuxdoc.org

Re: sourcenav deb dir layout

[Eray Ozkural]

"Mike A. Harris" wrote:
> 
> The funny thing though, is Source Navigator doesn't follow Red
> Hat conventions of file locations either.  ;o)  Red Hat 7.0 of
> course approaches FHS compliance, and both debian and Red Hat are
> becoming similar in this manner.
> 

Yeah, but deb packages strictly follow FHS compliance. It's a bug
if they don't. :)

> It turns out, source nav installs grep/egrep/fgrep and a slew of
> other utils into /usr/local/bin when built for /usr/local, and
> /usr/local was in the path first, so the sourcenav utils got used
> instead of /bin/grep, etc..  The problem is that the SourceNav
> grep and friends do not support all grep commandline options.  It
> took me a few days to figure this out..  ;o)
> 

burgh, a hacked grep? oh, no. i hadn't noticed that.

> To the fellow creating the deb packages, could you post your deb
> build files, (not the packages, just the deb equiv of .spec
> files) to me privately.  I'll share my .spec with you as well if
> you like.
> 

All right, I'm approaching a real package. just a couple of more
fixes, and I'm sending them to you.

> Perhaps we could take some of the changes that will be necessary
> in the build sections of our efforts and incorporate them
> directly into the Sourcenav makefiles, etc. and send patches in?
> 

Yep, I'm always trying to make a minimal number of changes (so
I can maintain them), I'll send you the changes as well.


Cheers,

-- 
Eray (exa) Ozkural
Comp. Sci. Dept., Bilkent University, Ankara
e-mail: erayo@cs.bilkent.edu.tr
www: http://www.cs.bilkent.edu.tr/~erayo

Re: sourcenav deb dir layout

[Syd Polk]

"Mike A. Harris" wrote:
> 
> On Tue, 17 Oct 2000, Syd Polk wrote:
> 
> >>i don't know where to put sdk, since sdk is not specific to sourcenav?
> >>if it is specific to sourcenav, then it also goes under share/sourcenav
> >>it looks like read only arch-independent data.
> >>
> >>Cheers,
> >
> >Source-Navigator is designed to integrated with the other gnu tools that
> >Red Hat offers, and has a directory structure which maps that. We will keep
> >these changes in mind, however.
> 
> The funny thing though, is Source Navigator doesn't follow Red
> Hat conventions of file locations either.  ;o)  Red Hat 7.0 of
> course approaches FHS compliance, and both debian and Red Hat are
> becoming similar in this manner.
> 

I should have said "Cygnus conventions". The gnu tools group has very little to
do with Red Hat 7. This will change over time, obviously.

> The reason I'm pointing this out is because I am trying to
> package Source Navigator for Red Hat right now, and having
> similar difficulties.  ;o)  The default install of a source nav
> build scatters files in odd locations as I found out the hard
> way..  ;o)  I had it build for /usr/local, and after installing
> had numerous problems as an ordinary user on my system.  Root,
> everything worked fine, but as a user, I had different problems
> running scripts, etc..
> 
> It turns out, source nav installs grep/egrep/fgrep and a slew of
> other utils into /usr/local/bin when built for /usr/local, and
> /usr/local was in the path first, so the sourcenav utils got used
> instead of /bin/grep, etc..  The problem is that the SourceNav
> grep and friends do not support all grep commandline options.  It
> took me a few days to figure this out..  ;o)

This is why I have been resistant to RPMs at this time. We are currently in the
process of removing grep from our build tree.
 
> What is the reasoning behind bringing a copy of grep and other
> utils with sourcenav? Is it for systems not having it?  If so,
> can I safely exclude it from the Red Hat packages?

We added some "features" to grep. Without snavigator's grep, the grep window
will not work.
 
> To the fellow creating the deb packages, could you post your deb
> build files, (not the packages, just the deb equiv of .spec
> files) to me privately.  I'll share my .spec with you as well if
> you like.
> 
> Perhaps we could take some of the changes that will be necessary
> in the build sections of our efforts and incorporate them
> directly into the Sourcenav makefiles, etc. and send patches in?
> 
> Well, one thing at a time I suppose.  ;o)
> 
> Take care everyone!
> TTYL
>

I have repeatedly stated that we will put out RPM versions of Source-Navigator
after we finish the 5.0 release, which should be late this year or early next
year. I know it is a long time to wait, but hopefully, these issues will have
disappeared by then.

Re: sourcenav deb dir layout

[Eray Ozkural]

Mo DeJong wrote:
> Guys, I thought we had been over this before. Yes, 4.5
> uses a custom grep that was forked a couple of years
> ago. The need for this custom grep has been removed
> in 5.0 because of all the problems it would create if
> you tried to make a RPM.

What 5.0? Isn't the last release 4.5.2?

Thanks,

-- 
Eray (exa) Ozkural
Comp. Sci. Dept., Bilkent University, Ankara
e-mail: erayo@cs.bilkent.edu.tr
www: http://www.cs.bilkent.edu.tr/~erayo

Re: sourcenav deb dir layout

[Mike A. Harris]

On Wed, 18 Oct 2000, Syd Polk wrote:

>> >Source-Navigator is designed to integrated with the other gnu tools that
>> >Red Hat offers, and has a directory structure which maps that. We will keep
>> >these changes in mind, however.
>> 
>> The funny thing though, is Source Navigator doesn't follow Red
>> Hat conventions of file locations either.  ;o)  Red Hat 7.0 of
>> course approaches FHS compliance, and both debian and Red Hat are
>> becoming similar in this manner.
>> 
>
>I should have said "Cygnus conventions". The gnu tools group
>has very little to do with Red Hat 7. This will change over
>time, obviously.

Yeah, thats ok..  I realize that it takes time to make the
changes.  Especially with something the size of source nav.

This is a big thing, and it will take some time I suspect.


>> It turns out, source nav installs grep/egrep/fgrep and a slew of
>> other utils into /usr/local/bin when built for /usr/local, and
>> /usr/local was in the path first, so the sourcenav utils got used
>> instead of /bin/grep, etc..  The problem is that the SourceNav
>> grep and friends do not support all grep commandline options.  It
>> took me a few days to figure this out..  ;o)
>
>This is why I have been resistant to RPMs at this time. We are
>currently in the process of removing grep from our build tree.

Oh, its no biggie once it is known.  I fully expected numerous
problems..  It's all part of the fun of packaging anything at all
really.  ;o)

 
>> What is the reasoning behind bringing a copy of grep and other
>> utils with sourcenav? Is it for systems not having it?  If so,
>> can I safely exclude it from the Red Hat packages?
>
>We added some "features" to grep. Without snavigator's grep, the grep window
>will not work.

Ok, makes sense.

 
>I have repeatedly stated that we will put out RPM versions of
>Source-Navigator after we finish the 5.0 release, which should
>be late this year or early next year. I know it is a long time
>to wait, but hopefully, these issues will have disappeared by
>then.

Yep, thats good.  Lots of people could benefit from the great
stuff already there though, so it doesn't hurt for me to try to
put out some RPM's right now.  It'll take some time though..  I
realize the scope, and am proceeding with caution anyways.  I
might not get it completed, but I'll certainly have fun
trying!  ;o) 

Thanks again,
TTYL



----------------------------------------------------------------------
      Mike A. Harris  -  Linux advocate  -  Open source advocate
              Computer Consultant - Capslock Consulting
                 Copyright 2000 all rights reserved
----------------------------------------------------------------------


Red Hat Linux:  http://www.redhat.com
Download for free:  ftp://ftp.redhat.com/pub/redhat/redhat-6.2/

Re: sourcenav deb dir layout

[Syd Polk]

At 04:31 PM 10/18/00 +0300, Eray Ozkural wrote:
>Mo DeJong wrote:
> > Guys, I thought we had been over this before. Yes, 4.5
> > uses a custom grep that was forked a couple of years
> > ago. The need for this custom grep has been removed
> > in 5.0 because of all the problems it would create if
> > you tried to make a RPM.
>
>What 5.0? Isn't the last release 4.5.2?
>
>Thanks,

We are working right now on the next release, which is the 5.0 release. It 
is an upgrade to the incr Tcl code now in the product.


Syd Polk		spolk@redhat.com
Engineering Manager	+1 415 777 9810 x 241
Red Hat, Inc.

Re: sourcenav deb dir layout

[Syd Polk]

At 04:28 PM 10/18/00 +0300, Eray Ozkural wrote:
>"Mike A. Harris" wrote:
> >
> > The funny thing though, is Source Navigator doesn't follow Red
> > Hat conventions of file locations either.  ;o)  Red Hat 7.0 of
> > course approaches FHS compliance, and both debian and Red Hat are
> > becoming similar in this manner.
> >
>
>Yeah, but deb packages strictly follow FHS compliance. It's a bug
>if they don't. :)

What is FHS, anyway?


Syd Polk		spolk@redhat.com
Engineering Manager	+1 415 777 9810 x 241
Red Hat, Inc.

Re: sourcenav deb dir layout

[Eray Ozkural]

Syd Polk wrote:
> 
> >Yeah, but deb packages strictly follow FHS compliance. It's a bug
> >if they don't. :)
> 
> What is FHS, anyway?
> 

Ahem, this is something debian developers have been wrestling over
for many months. :) 

From /usr/share/doc/debian-policy/fhs/fhs.txt.gz

                     Filesystem Hierarchy Standard -- Version 2.1

                         Filesystem Hierarchy Standard Group
                               edited by Daniel Quinlan


                                       ABSTRACT

                 This standard consists of a set of requirements and
            guidelines for file and directory placement under UNIX-like
            operating systems.  The guidelines are intended to support
            interoperability of applications, system administration tools,
            development tools, and scripts as well as greater uniformity
            of documentation for these systems.


       April 12, 2000


Please see debian policy documents to see how it is used in debian.
Just go to www.debian.org ;)

Cheers,

-- 
Eray (exa) Ozkural
Comp. Sci. Dept., Bilkent University, Ankara
e-mail: erayo@cs.bilkent.edu.tr
www: http://www.cs.bilkent.edu.tr/~erayo

Re: sourcenav deb dir layout

[Syd Polk]

At 12:27 AM 10/18/00 -0700, Mo DeJong wrote:
>On Wed, 18 Oct 2000, Ben Elliston wrote:
>
> >    What is the reasoning behind bringing a copy of grep and other utils
> >    with sourcenav? Is it for systems not having it?  If so, can I safely
> >    exclude it from the Red Hat packages?
> >
> > The version of grep that is built by S-N includes a number of command line
> > options that were necessary to make it work better with S-N -- for 
> instance,
> > it emitted progress indication to stderr which S-N used to give visual
> > feedback of grep's progress.
> >
> > I believe the current version eliminates the need for a special version of
> > grep, but I could be mistaken.  I'll leave that up to one of the current
> > team to speak about.
> >
> > Ben
>
>Guys, I thought we had been over this before. Yes, 4.5
>uses a custom grep that was forked a couple of years
>ago. The need for this custom grep has been removed
>in 5.0 because of all the problems it would create if
>you tried to make a RPM.
>
>I still think it is great that you gents are willing to
>go through the pain of creating deb/rpm package for
>4.5, but I still think you should just put everything
>in a sn root (like /usr/sourcenav) and be done
>with it. You are going to have nothing but problems
>trying to get the 4.5 codebase to play nice with
>the other executables in /usr.
>
>Toasted executables:
>
>egrep
>fgrep
>grep
>itclsh3.0
>itkwish3.0
>tclsh
>wish

Actually, the only ones of these that "make install" clobbers is grep and 
wish. We need our version of grep, and the wish is because "make install" 
assumes you are building a version that will be installed via "INSTALL".


Syd Polk		spolk@redhat.com
Engineering Manager	+1 415 777 9810 x 241
Red Hat, Inc.

Re: sourcenav deb dir layout

[Mike A. Harris]

On Wed, 18 Oct 2000, Syd Polk wrote:

>> > The funny thing though, is Source Navigator doesn't follow Red
>> > Hat conventions of file locations either.  ;o)  Red Hat 7.0 of
>> > course approaches FHS compliance, and both debian and Red Hat are
>> > becoming similar in this manner.
>> >
>>
>>Yeah, but deb packages strictly follow FHS compliance. It's a bug
>>if they don't. :)
>
>What is FHS, anyway?

The "File Heirarchy Standard".  It started out as the "Linux
Filesystem Standard (FSSTND)" years ago, which had the goal of
defining the meanings of the system directories such as /usr,
/bin, /home, /etc, and so on.  They renamed it to the FHS with
hopes it would be adopted on non-Linux systems as well.

Enhancements have been made to the document to solve different
problems that have come up, and most distributions, including Red
Hat are trying to follow the standard so that there is a common
ground of where to place files, config files, libraries, data,
etc..

Most distributions are FHS compliant to some degree or another,
and Red Hat 7.0 seems to be quite so as I understand.  The more
compliant all dists are, the more interoperability there is.

You can read the FHS document at:

http://www.pathname.com/fhs

It is one of the most important Linux standards documents there
are right now IMHO, so it helps out a lot as a programmer to get
as familiar with it as possible, since everyone is going to
ultimately be using it.

Other standards are the Linux Standard Base:

http://www.linuxbase.org

And also:

http://www.freestandards.org


Hope this helps!
Take care,
TTYL


----------------------------------------------------------------------
      Mike A. Harris  -  Linux advocate  -  Open source advocate
              Computer Consultant - Capslock Consulting
                 Copyright 2000 all rights reserved
----------------------------------------------------------------------

#[Mike A. Harris bash tip #3 - how to disable core dumps]
# Put the following at the bottom of your ~/.bash_profile
ulimit -c 0

Re: sourcenav deb dir layout

[Ben Elliston]

   Actually, the only ones of these that "make install" clobbers is grep
   and wish. We need our version of grep, and the wish is because "make
   install"  assumes you are building a version that will be installed
   via "INSTALL".

Is the intention that the INSTALL script will vanish in favour of just `make
install'?

Ben