[gentoo-dev] gentoo & fhs

[gentoo-dev] gentoo & fhs

[Collins]

Just finished a lengthy interchange wih a "gentleman" (loosely
speaking) on another group this weekend.  Said gentleman considers
himself to be a chief priest of the fhs religion, and he says that he
wouldn't touch gentoo with a fork because gnome and kde are in the
/usr hierarchy instead of the /opt hierarchy "where god intended them
to be."

Just curious, is he all wet, or is this a conscious departure from the
fhs requirements?

-- 
Collins Richey - Denver Area - WWTLRD?
gentoo(since 01/01/01) 2.4.18+(ext3) xfce-sylpheed-mozilla

Re: [gentoo-dev] gentoo & fhs

[Miguel S. Filipe]

Collins wrote:

>Just finished a lengthy interchange wih a "gentleman" (loosely
>speaking) on another group this weekend.  Said gentleman considers
>himself to be a chief priest of the fhs religion, and he says that he
>wouldn't touch gentoo with a fork because gnome and kde are in the
>/usr hierarchy instead of the /opt hierarchy "where god intended them
>to be."
>
>Just curious, is he all wet, or is this a conscious departure from the
>fhs requirements?
>
>  
>
I do touch gentoo, but I also would like if gentoo would put those "mega 
apps" (kde and gnome)
in the /opt, I don't know if there is any rule* about this, I just like 
them better in /opt..


Something that might be related to this is the question:
Does gentoo folows the linux standart base? url: http://www.linuxbase.org

*: after looking in google it seems that there exists a supposed standart
File Hierarchy Standart url: http://www.pathname.com/fhs

What do developers and Drobbins think of this, {should,are,must} any of 
this standarts be followed?

Miguel Sousa Filipe
gentoo user in .pt (PORTUGAL)
handle: m3thos
more human than human

Re: [gentoo-dev] gentoo & fhs

[Spider]

[-- Attachment #1: Type: text/plain, Size: 1307 bytes --]

I think this is the best explination of it :

http://www.pathname.com/fhs/2.2/fhs-3.12.html

since we dont "add on" either KDE or Gnome I say... Give the man a
balloon.


compare with this though:
<quote>
Large software packages must not use a direct subdirectory under the
/usr hierarchy. 
</quote>
http://www.pathname.com/fhs/2.2/fhs-4.1.html


//Spider


begin  quote
On Mon, 1 Jul 2002 17:37:35 -0600
Collins <erichey2@attbi.com> wrote:

> Just finished a lengthy interchange wih a "gentleman" (loosely
> speaking) on another group this weekend.  Said gentleman considers
> himself to be a chief priest of the fhs religion, and he says that he
> wouldn't touch gentoo with a fork because gnome and kde are in the
> /usr hierarchy instead of the /opt hierarchy "where god intended them
> to be."
> 
> Just curious, is he all wet, or is this a conscious departure from the
> fhs requirements?
> 
> -- 
> Collins Richey - Denver Area - WWTLRD?
> gentoo(since 01/01/01) 2.4.18+(ext3) xfce-sylpheed-mozilla
> _______________________________________________
> gentoo-dev mailing list
> gentoo-dev@gentoo.org
> http://lists.gentoo.org/mailman/listinfo/gentoo-dev


--
begin  .signature
This is a .signature virus! Please copy me into your .signature!
See Microsoft KB Article Q265230 for more information.
end

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] gentoo & fhs

[Spider]

[-- Attachment #1: Type: text/plain, Size: 1105 bytes --]

begin  quote
On Mon, 1 Jul 2002 19:06:27 -0600
Collins <erichey2@attbi.com> wrote:
> 
> It sounds a lot like ex-president Clinton - "It depends on the meaning
> of is."
he.

 
> What does the term "add on" mean?  Isn't every package other the the
> kernel, gnu stuff, etc. an "add on"?


in our case, what is not locally compiled through portage is considered
an "add-on" that means things like JDK's, Opera, OpenOffice-bin,
Netscape 4.x and other binary-only applications.

emerge's go as "system" since the emerge command specifies that this
should be part of your installation, and it is something we provide with
our OS, not an "add-on" to it.

fex. A user can bootstrap, then just "emerge kde" and have a fully
functional (supposedly) system.


I've cc'd the list because this is relevant to them, please do the same
in the future.


//Spider
 
> -- 
> Collins Richey - Denver Area - WWTLRD?
> gentoo(since 01/01/01) 2.4.18+(ext3) xfce-sylpheed-mozilla


--
begin  .signature
This is a .signature virus! Please copy me into your .signature!
See Microsoft KB Article Q265230 for more information.
end

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] gentoo & fhs

[Collins]

On Tue, 2 Jul 2002 03:47:31 +0200 Spider <spider@gentoo.org> wrote:
> begin  quote
> On Mon, 1 Jul 2002 19:06:27 -0600
> Collins <erichey2@attbi.com> wrote:
> > 
> > It sounds a lot like ex-president Clinton - "It depends on the
> > meaning of is."
> he.
> 
>  
> > What does the term "add on" mean?  Isn't every package other the
> > the kernel, gnu stuff, etc. an "add on"?
> 
> 
> in our case, what is not locally compiled through portage is
> considered an "add-on" that means things like JDK's, Opera,
> OpenOffice-bin, Netscape 4.x and other binary-only applications.
> 
> emerge's go as "system" since the emerge command specifies that this
> should be part of your installation, and it is something we provide
> with our OS, not an "add-on" to it.
> 
> fex. A user can bootstrap, then just "emerge kde" and have a fully
> functional (supposedly) system.
> 
> 
> I've cc'd the list because this is relevant to them, please do the
> same in the future.

OK, that much is clear.  So how do you resolve /usr/kde/2 ... with the
prohibition you've cited?

"Large software packages must not use a direct subdirectory under the
/usr hierarchy."
 
-- 
Collins Richey - Denver Area - WWTLRD?
gentoo(since 01/01/01) 2.4.18+(ext3) xfce-sylpheed-mozilla

Re: [gentoo-dev] gentoo & fhs

[Alexander Gretencord]

Collins wrote:

>OK, that much is clear.  So how do you resolve /usr/kde/2 ... with the
>prohibition you've cited?
>
>"Large software packages must not use a direct subdirectory under the
>/usr hierarchy."
> 
>  
>
I've talked about this to a gentoo dev too. The problem is that gentoo 
considers everything that's not binary-only part of the system (I think 
that's ok by the definition as they "ship" that software with their 
distribution (if you made a cd)).

That sentence about "no subdirs in /usr" makes the situation difficult 
for gentoo. /usr/local is for the local administrator so gentoo can't 
install there, gentoo has a rule that only binary packages get into 
/opt, but /opt is the only part of the filesystem that subdirs are 
allowed in for individual packages according to the fhs. And you can 
really understand why one wouldn't want to have gnome or kde installed 
directly into /usr (which would be the only gentoo+fhs compliant solution).

Can anyone lighten me up on why there should be no subdirs in /usr ?

Alex

Re: [gentoo-dev] gentoo & fhs

[Karl Trygve Kalleberg]

On Tue, 2 Jul 2002, Alexander Gretencord wrote:

> Can anyone lighten me up on why there should be no subdirs in /usr ?

That messes up its nice {bin,share,lib,sbin} structure. If you need
subdirs, you should install into /opt. 

Nice concept really: "for large, clunky stuff, check out /opt; for useful
tools, check out /usr" :P

Karl T

Re: [gentoo-user] Re: [gentoo-dev] gentoo & fhs

[Grant Goodyear]

> OK, that much is clear.  So how do you resolve /usr/kde/2 ... with the
> prohibition you've cited?

It's an exception because we support both kde2 and kde3, but they
conflict.  The FHS doesn't have an obvious rule for this case.
Presumably in the future we will be able to drop kde2 and put
kde3 stuff directly into /usr, where it belongs.

-g2boojum-

Re: [gentoo-user] Re: [gentoo-dev] gentoo & fhs

[Maciek Borowka]

Quoting Grant Goodyear <grant@grantgoodyear.org>:

> > OK, that much is clear.  So how do you resolve /usr/kde/2 ... with the
> > prohibition you've cited?
> 
> It's an exception because we support both kde2 and kde3, but they
> conflict.  The FHS doesn't have an obvious rule for this case.
> Presumably in the future we will be able to drop kde2 and put
> kde3 stuff directly into /usr, where it belongs.

Yes, until we have kde4, and then gnome3 and so on... We will never avoid
/usr/kde/?/ directories and imho it is a very good idea to keep it like that.
Gentoo is the first distribution where I can finally do an "ls /usr/bin/*". 
And I like it, even if it is not very fhs compilant./.


Anyway, just my 2 eurocents,
/Maciek




-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/

Re: [gentoo-user] Re: [gentoo-dev] gentoo & fhs

[Jean-Michel Smith]

On Tuesday 02 July 2002 07:53 am, Grant Goodyear wrote:
> > OK, that much is clear.  So how do you resolve /usr/kde/2 ... with the
> > prohibition you've cited?
>
> It's an exception because we support both kde2 and kde3, but they
> conflict.  The FHS doesn't have an obvious rule for this case.
> Presumably in the future we will be able to drop kde2 and put
> kde3 stuff directly into /usr, where it belongs.

The FHS or Gentoo need to address this in some fashion.  This sort of 
conflict, where older and newer versions of SomeApp are needed in parallel, 
but conflict, isn't going to go away (even if the specific instance of kde2 
v. kde3 does).

Perhaps the Gentoo rule of "binaries-only in /opt" needs to be relaxed to "all 
binaries into /opt, as well as all monolithically large applications that 
require their own subdirectory, even if compiled from source [e.g. gnome1 v. 
gnome2, kde2 v. kde3, etc.])

I have no real opinion on this, since exceptions to FHS that make sense aren't 
IMHO all that bad, but I could see where /usr/gnome1, /usr/gnome2, /usr/kde2, 
/usr/kde3, etc. could start to get out of hand, especially if we ever end up 
with /usr/openoffice1, /usr/openoffice2, and so on...in which case something 
like the above rule for /opt might make more sense.

Jean.

Re: [gentoo-user] Re: [gentoo-dev] gentoo & fhs

[Bart Verwilst]

On Tuesday 02 July 2002 14:53, Grant Goodyear wrote:
|| It's an exception because we support both kde2 and kde3, but they
|| conflict.  The FHS doesn't have an obvious rule for this case.
|| Presumably in the future we will be able to drop kde2 and put
|| kde3 stuff directly into /usr, where it belongs.

Heh, and what will you do when kde4 comes out? :o)


-- 
Bart Verwilst
Gentoo Linux Developer, Release Coordinator
Gent, Belgium

[gentoo-dev] Why the FHS can't be followed

[Dan Armak]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 02 July 2002 05:38, Collins wrote:
> OK, that much is clear.  So how do you resolve /usr/kde/2 ... with the
> prohibition you've cited?
>
> "Large software packages must not use a direct subdirectory under the
> /usr hierarchy."

<sorry, I sent a personal reply to Collins before realizing I should have used 
reply-to-list>

If KDE lives directly in /usr (i.e. binaries in /usr/bin etc.) then you cannot 
have more than one version of kde installed at a time. More than that, you 
cannot have more than one version of kdelibs at a time, so if you have kde3 
in /usr you can't run kde2 apps. And some people need to do just that because 
not all kde2 apps have been ported to kde3 yet.

Last autumn we tried to make KDE live in /usr with just kdelibs living 
separately in /usr/lib/kde/2,3. I spent 3 months trying to make it work to 
keep the fhs guys happy and came to the conclusion it just isn't meant to be. 
It may be possible, but it's very ugly.

This is mainly because some KDE apps work on the assumption that they are 
installed in the same path as the kdelibs they're linked against. Koffice for 
one. There are ways around that but they don't always work. Fex. one of the 
things that never worked was noatun. When I askd the kde devs for help on how 
to make noatun work when installed outside the kdelibs directory they 
explicitly told me: it's not supposed to be done (in this case, couldn't be 
without playing with symlniks - ugh). KDE needs to live in its own dir 
outside the standard path. That's what $KDEDIR[S] is for and if we don't do 
it that way we'll come to no good.

And since we've come to the conclusion we can't put it in /opt, /usr/kde/2,3 
(or equivalent) is the only option left. The fhs doesn't provide for having 
more than one version of a package installed at a time but we have to do it 
with qt2/3 and kdelibs2/3 (and gnome 1.4/2). I prefer that option over 100% 
FHS compliance.

End rant mode. I guess I just had leftover frustration stored from the time I 
actually tried to make this work. Maybe we can put a version of this in a FAQ 
somewhere because this isn't the first time this question has been asked. 
Maybe if that fhs guy saw it he'd think twice before blaming us. The fhs just 
doesn't accomodate certain things.

- - -- 
Dan Armak
Gentoo Linux developer (KDE)
Matan, Israel

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9IfPfUI2RQ41fiVERAn+oAJ98b5HYIcdJeo8y3c8oAno7ePaE9wCffeuH
r/z14kJYKb1TlCC/zDo1Zrc=
=gV/d
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Why the FHS can't be followed

[Jean-Michel Smith]

On Tuesday 02 July 2002 01:41 pm, Dan Armak wrote:

> And since we've come to the conclusion we can't put it in /opt,
> /usr/kde/2,3 (or equivalent) is the only option left. The fhs doesn't
> provide for having more than one version of a package installed at a time
> but we have to do it with qt2/3 and kdelibs2/3 (and gnome 1.4/2). I prefer
> that option over 100% FHS compliance.

I find the use of a .../kde/2 and .../kde/3 directory to be very useful, and 
your reasoning for doing so certainly seems sound to myself (speaking as a 
more or less 'outside' observer).

However, I'm a little confused why (or how) it was decided that /opt would be 
an inappropriate place to have put this.  In other words, why is /usr/kde/3 
and /usr/kde/2 better than /opt/kde/3 and /opt/kde/2?  I'm not criticizing (I 
have no real opinion on FHS compliance, or lack thereof, at all), I'm just 
wondering what the rationale is for not wanting to put things like this in 
/opt.

Jean.

Re: [gentoo-dev] Why the FHS can't be followed

[Luke Ravitch]

On 2002-07-02 12:09, Jean-Michel Smith <jsmith@kcco.com> wrote:
> However, I'm a little confused why (or how) it was decided that /opt
> would be an inappropriate place to have put this.  In other words,
> why is /usr/kde/3 and /usr/kde/2 better than /opt/kde/3 and
> /opt/kde/2?  I'm not criticizing (I have no real opinion on FHS
> compliance, or lack thereof, at all), I'm just wondering what the
> rationale is for not wanting to put things like this in /opt.

My feeling is that nothing in the /usr tree should depend on anything
in /opt.  Things in /opt are meant to be self-contained.  If we put
Gnome and KDE in /opt, where do we put apps that optionally depend on
them?  E.g, XMMS isn't really a gnome app (and so shouldn't be under
/opt/gnome) but can have Gnome dependencies (for the applet).

Gnome and KDE are most like X.  X has its own directory in /usr.  It
is part of the system.  As such, it's not such a big deal if programs
that depend on X live outside the X tree.  Of course, the FHS
considers /usr/X11 an unfortunate goof that, sadly, needs to be kept
around because of the tremendous inertia behind it.

Though I'm generally a big supporter, I think the FHS might be wrong
on this one.  Gnome and KDE should go under /usr/gnome and /usr/kde.
I do agree that adding an immediate subdirectory of /usr is not
something that should be taken lightly.  However, Gnome and KDE are
significantly entrenched as part of Gentoo that they might warrant an
X-like exception.

Another idea (likely a better one) is to put Gnome and KDE in their
own directories under /usr/X11R6.  FreeBSD has GTK and Gnome apps (I
don't know what they do with KDE, I imagine it's similar) in the X11
tree.  That's always seemed right to me.  But they put them in there
like we dump Gnome into /usr, so there isn't the advantage of separate
trees for separate versions.  I think /usr/X11R6/gnome and
/usr/X11R6/kde trees could really work out well.  And I don't think
the FHS regulates the contents of the X11 tree, so we'd keep them
happy as well.

My $0.02.

-- 
Luke

Re: [gentoo-dev] Why the FHS can't be followed

[Jean-Michel Smith]

On Tuesday 02 July 2002 03:06 pm, Luke Ravitch wrote:
> My feeling is that nothing in the /usr tree should depend on anything
> in /opt.  Things in /opt are meant to be self-contained.  If we put
> Gnome and KDE in /opt, where do we put apps that optionally depend on
> them?  E.g, XMMS isn't really a gnome app (and so shouldn't be under
> /opt/gnome) but can have Gnome dependencies (for the applet).

That is a very interesting point I hadn't considered.  I think I agree with
you as well (not that my personal opinion matters a whole lot in this context
:)

> Though I'm generally a big supporter, I think the FHS might be wrong
> on this one.  Gnome and KDE should go under /usr/gnome and /usr/kde.
> I do agree that adding an immediate subdirectory of /usr is not
> something that should be taken lightly.  However, Gnome and KDE are
> significantly entrenched as part of Gentoo that they might warrant an
> X-like exception.

This is a problem we're going to keep running into, perhaps more commonly as
large, free(dom) office suites, new desktops like gnustep and enlightenment,
etc. mature.  Perhaps we should be looking for a more general solution,
rather than making exceptions for gnome and KDE.

I mean, if we've decided the FHS is wrong on this particular point, why not
make the fix more general and all-encompassing?

I would prefer to see /usr/X11R6 remain a relatively "pure" X tree (I never
liked the way Mandrake dumped a lot of non-core 3rd party X apps into
/usr/X11R6/bin, for example), and I do not think /usr/X11R6 offers a general
solution.  What about a big database or SAP application that has no GUI, but
is monstrous and demanding of its own tree, yet for whatever reason doesn't
belong in /opt?

I don't have any bright ideas on what the directory should be called, per se,
and I'm sure someone will think of a more clever name than this, but if we're
going to deviate from the FHS why not make it for just ONE directory, beneath
which subdirectories for large, free package suites like KDE, Gnome,
Enlightenment, etc could reside.  Something like:

/usr/sw/kde/2
/usr/sw/kde/3
/usr/sw/gnome/1
/usr/sw/gnome/2
/usr/sw/enlightenment/16
/usr/sw/enlightenment/17

and so on.  (sw=software, not a very imaginative name.  Perhaps the long 
version is better, e.g. /usr/software/kde/2, etc.)

In any event, the deviation from the FHS would be limited to one directory and
more or less isolated from the rest of the filesystem tree.  Indeed, given
that the FHS doesn't consider the possibility of keeping around multiple
versions of large software suites like KDE and Gnome (something which
*should* be provided for, as that is in keeping with UNIX's tradition of
allowing versioned libraries, etc. to coexist nicely), perhaps such a
solution could be proposed as an amendment to the FHS.

Anyway, just some thoughts from the peanut gallary for your consideration.

Jean.

Re: [gentoo-dev] Why the FHS can't be followed

[Luke Ravitch]

On 2002-07-02 15:04, Jean-Michel Smith <jsmith@kcco.com> wrote:
> This is a problem we're going to keep running into, perhaps more commonly as
> large, free(dom) office suites, new desktops like gnustep and enlightenment,
> etc. mature.  Perhaps we should be looking for a more general solution,
> rather than making exceptions for gnome and KDE.

I think the /usr/X11R6 approach scales nicely for things like GNUstep
or maybe XFce (don't know much about XFce).  I don't know that E
really calls for its own directory tree yet.  If we think that makes
/usr/X11R6 too cluttered, we could always do something like
/usr/X11R6/desktops.  However, I prefer /usr/X11R6/gnome,
/usr/X11R6/kde, /usr/X11R6/gnustep, etc.

> I mean, if we've decided the FHS is wrong on this particular point, why not
> make the fix more general and all-encompassing?

We (well, _I_) haven't totally decided that it's wrong.  (Still
debating.)  By my reading, putting X-based desktop environments (e.g,
Gnome and KDE) in their own trees under /usr/X11R6 is FHS compatible.
Adding a directory directly under /usr is clearly a violation.

> I would prefer to see /usr/X11R6 remain a relatively "pure" X tree (I never
> liked the way Mandrake dumped a lot of non-core 3rd party X apps into
> /usr/X11R6/bin, for example), and I do not think /usr/X11R6 offers a general

The X tree was never really meant to be "pure".  Look at the whole
xmkmf thing.  "Normal" X programs go in the /usr/X11R6 tree.

> solution.  What about a big database or SAP application that has no GUI, but
> is monstrous and demanding of its own tree, yet for whatever reason doesn't
> belong in /opt?

Those seem like exactly why /opt exists.  Gnome and KDE are
infrastructure, they aren't really "applications".  And, since they
are in many ways extensions on X, I think it makes sense to put them
under the X tree.  The home for monstrous _applications_ (like office
suites or database apps) that demand their own trees and are
self-contained (i.e., nothing depends on them) is /opt.

I only see an exception for things like Gnome and KDE.  (Because, like
X, other applications depend on them.)  And those can't pop up too
often.  Also, we should avoid giving things their own directory tree
unless it's really, really justified.  (The Stow fans are surely gonna
beat me up over that one ;-)

> I don't have any bright ideas on what the directory should be called, per se,
> and I'm sure someone will think of a more clever name than this, but if we're
> going to deviate from the FHS why not make it for just ONE directory, beneath
> which subdirectories for large, free package suites like KDE, Gnome,
> Enlightenment, etc could reside.  Something like:
> 
> /usr/sw/kde/2
> /usr/sw/kde/3
> /usr/sw/gnome/1
> /usr/sw/gnome/2
> /usr/sw/enlightenment/16
> /usr/sw/enlightenment/17
> 
> and so on.  (sw=software, not a very imaginative name.  Perhaps the long 
> version is better, e.g. /usr/software/kde/2, etc.)

The idea has merit, but I'm too concerned that this would encourage
putting too many things into /usr/software.  Stow is fine in the
/usr/local tree for those who like it, but I don't think Gentoo should
embrace it (or something like it) for system packages (i.e., anything
in /usr except for /usr/local).

> In any event, the deviation from the FHS would be limited to one
> directory and more or less isolated from the rest of the filesystem
> tree.  Indeed, given that the FHS doesn't consider the possibility
> of keeping around multiple versions of large software suites like
> KDE and Gnome (something which *should* be provided for, as that is
> in keeping with UNIX's tradition of allowing versioned libraries,
> etc. to coexist nicely), perhaps such a solution could be proposed
> as an amendment to the FHS.

Unix is traditionally good at handling multiple library versions, but
there hasn't been great support for multiple application versions.
(Various sysadmin-specific kludges exist.)  I think that's okay.  I
can run Gnome 1.4 apps under Gnome 2 with only one Gnome tree.  But I
only have one version of each Gnome app.  Good enough for me.

QT makes things stickier for a source-based distro because it requires
all that precompiling stuff.  So, though it's not my absolute
favorite, I'd be okay with something like:

     /usr
       +--->X11R6
             +--->gnome
             |     +--->1
             |     +--->2
             +--->kde
                   +--->2
                   +--->3

Though I'd kinda prefer something like:

     /usr
       +--->X11R6
             +--->gnome1
             +--->gnome2
             +--->kde2
             +--->kde3

That way we don't have to type as many slashes ;-)

With only a couple versions of each desktop environment (or do people
still depend on KDE 1 apps?) and two, three, or four desktop
environments, that's quite manageable.

So I vote for one of the above to layouts.  Picking the right one is a
matter of decided which gives the best breadth/depth ratio.

-- 
Luke

Re: [gentoo-dev] Why the FHS can't be followed

[Fuper]

On Tue, 2002-07-02 at 20:54, Luke Ravitch wrote:
> I'd be okay with something like:
> 
>      /usr
>        +--->X11R6
>              +--->gnome
>              |     +--->1
>              |     +--->2
>              +--->kde
>                    +--->2
>                    +--->3
> So I vote for one of the above to layouts.  Picking the right one is a
> matter of decided which gives the best breadth/depth ratio.

I agree.  The whole discussion seems to move toward that conclusion.  I
also now agree that Gentoo is not FHS compatible because it defines
non-standard directories in /usr.

Now, as for Stow -- I beat you up for not loving Stow!  I may find some
drawbacks in the future that are not apparent to me now but it seems to
me that the tiny Stow script makes it possible to install, upgrade, and
remove software packages without depending on a database to track all of
the files.  For example, I can answer the following questions without
reference to an rpm or dpkg (or portage) database:

Q:  Which files were installed by FramerD?  
(A: All of the files in /usr/local/stow/framerd-2.3/

Q:  How can I upgrade mit-scheme from version 7.7 to 7.7.1?
(A: cd /usr/local/stow; stow -D scheme-7.7; stow scheme-7.7.1


Q:  Which binaries are used for accessing Wordnet?
(A: ls /usr/local/stow/wordnet-1.7/bin
 or ls -l /usr/local/bin | grep wordnet

That last one works because every binary is symlinked into local/bin and
so ls -l gives a clear view of what package each binary belongs to; e.g.

wishwn -> ../stow/wordnet-1.7/bin/wishwn
wn -> ../stow/wordnet-1.7/bin/wn
wnb -> ../stow/wordnet-1.7/bin/wnb

[gentoo-dev] Stow (Was: Why the FHS can't be followed)

[Wout Mertens]

Hey there,

On 2 Jul 2002, Fuper wrote:

> On Tue, 2002-07-02 at 20:54, Luke Ravitch wrote:

> Now, as for Stow -- I beat you up for not loving Stow!  I may find some
> drawbacks in the future that are not apparent to me now but it seems to
> me that the tiny Stow script makes it possible to install, upgrade, and
> remove software packages without depending on a database to track all of
> the files.  For example, I can answer the following questions without
> reference to an rpm or dpkg (or portage) database:
[...]

I agree, stow is cool and at work we use it to maintain our 12GB
/usr/local tree that is exported over nfs to our workstations.
Some drawbacks, however:

- You have a slight speed loss because of the symlinking adding
  extra lookups. Luckily, Linux has very good caching :)

- Some packages hate it when you symlink stuff; e.g. sudo needs its
  sudoers file to be a regular file. Granted, this is a configuration file
  and as such may not need to be symlinked in a general gentoo context, so
  this could be solved by just creating a regular file in the
  pkg_postinst.

- stow -R can grind your server to a screeching halt if you have many
  files. I'm sure this is solveable by rewriting the code a little, and I
  don't know if recent versions have trouble with it since we don't try it
  anymore ;)

- You have a lot of symlinks in your /usr, which makes ls -l a bit less
  attractive to look at. Of course, there's still ls -lL ;-)

I've been considering nagging to drobbins about changing Portage so that
merging actually means
'Copy package to /var/db/packages/<cat>/<pkg>/files/ and symlink everything'
and unmerging means 'remove the symlinks'. Portage would then need a
purge option to remove the package files altogether.

This would have the advantage that you can always revert to a certain
version of a package with certainty, since no files are removed from the
previous package. And you see where a file comes from really quickly by
looking at the symlink, which is very useful.

And actually, I think it would be possible to let portage optionally have
that feature, because the only thing it changes is where the files are
installed and what merge and unmerge do. All the rest would stay the
same. That way, people who want it can turn it on and the rest aren't
bothered.

Thoughts?

Wout.

Re: [gentoo-dev] Stow (Was: Why the FHS can't be followed)

[Brian Webb]

First, I like your idea of supporting a symlinked package model in
portage.  I think that would be a great addition, and I don't think it
should be very hard.  We also use a similar system at work.  I wish
portage ebuilds supported a $PREFIX variable so that ebuilds could be used
to install into /usr/local (or wherever).

For those who may be new to stow, et. al.  An alternative to stow that I
think has some advantages is the Encap Package Manager: epkg
http://www.encap.org/epkg.  It's written in C (rather than perl), and it
supports more automated versioning.  My intent is not to start a "this is
better that that" war.  Just wanted to give an alternative to those that
are new to the concept. ;-)

Brian


> I agree, stow is cool and at work we use it to maintain our 12GB
> /usr/local tree that is exported over nfs to our workstations.
> Some drawbacks, however:
>
> - You have a slight speed loss because of the symlinking adding
>   extra lookups. Luckily, Linux has very good caching :)
>
> - Some packages hate it when you symlink stuff; e.g. sudo needs its
>   sudoers file to be a regular file. Granted, this is a configuration
> file and as such may not need to be symlinked in a general gentoo
> context, so this could be solved by just creating a regular file in
> the
>   pkg_postinst.
>
> - stow -R can grind your server to a screeching halt if you have many
>   files. I'm sure this is solveable by rewriting the code a little, and
> I don't know if recent versions have trouble with it since we don't
> try it anymore ;)
>
> - You have a lot of symlinks in your /usr, which makes ls -l a bit less
>   attractive to look at. Of course, there's still ls -lL ;-)
>
> I've been considering nagging to drobbins about changing Portage so that
> merging actually means
> 'Copy package to /var/db/packages/<cat>/<pkg>/files/ and symlink
> everything' and unmerging means 'remove the symlinks'. Portage would
> then need a purge option to remove the package files altogether.
>
> This would have the advantage that you can always revert to a certain
> version of a package with certainty, since no files are removed from the
> previous package. And you see where a file comes from really quickly by
> looking at the symlink, which is very useful.
>
> And actually, I think it would be possible to let portage optionally
> have that feature, because the only thing it changes is where the files
> are installed and what merge and unmerge do. All the rest would stay the
> same. That way, people who want it can turn it on and the rest aren't
> bothered.

Re: [gentoo-dev] Stow (Was: Why the FHS can't be followed)

[Fuper]

On Fri, 2002-07-05 at 11:59, Brian Webb wrote:
> For those who may be new to stow, et. al.  An alternative to stow that I
> think has some advantages is the Encap Package Manager: epkg
> http://www.encap.org/epkg.  It's written in C (rather than perl), and it
> supports more automated versioning.  My intent is not to start a "this is
> better that that" war.  Just wanted to give an alternative to those that
> are new to the concept. ;-)

Hey, great.  I don't like the default behavior of installing the
"latest" version but it is flexible (you can specify a specific
version).  Encap does something that I wanted --- it can ignore certain
directories in a package (e.g if a package is "built in place" then
encap could be asked to ignore the <package>/src directory).  It is also
an advantage to have it written in C so that it can used earlier in a
system-installation process (perl is no longer in the base install of
some systems).  As far as I can see Encap is compatible with stow and
one could use either alternately.  I'll give Encap a try.

Thanks Brian.

-- 
Fuper, Memphis, LPIC-1

Re: [gentoo-dev] Stow (Was: Why the FHS can't be followed)

[Alexander Gretencord]

http://lists.gentoo.org/pipermail/gentoo-dev/2002-June/012517.html

You've got my support :)

Alex

Re: [gentoo-dev] Why the FHS can't be followed

[Fuper]

The FHS _has_ been followed by Gentoo.

The use of /opt is optional.  The Standard places limitations on the use
of /opt and gives an historic rationale for it, but does not require
that anything be installed in /opt.

I would suggest that everyone actually read the FHS at
<http://www.pathname.com/fhs/>

BTW the restrictions are that any package installed in /opt must reside
entirely within it's own subdirectory /opt/<package> and that no package
may modify or delete software installed in /opt by the local system
administrator. Only the local administrator may install files into the
directories: /opt/bin /opt/include /opt/lib /opt/man /opt/info

Especially read the Rationale for /opt --- it was an AT&T System V
invention and is to hold "Add-on Software Packages" that are not a part
of the "System Software".  That made sense for System V for which
"System Software" had a definition.  There is much less clear
distinctions between "system" and "add-on" in a Linux system.  There is
no distinction between "system" and "add-on" in the Gentoo
meta-distribution.  In a meta-distribution it's all under local
administrator control.  

/opt is optional

BTW I prefer to place binary-only packages such as Acroread in /opt and
otherwise to keep /opt as small as possible.  I don't put any local
software in /opt and don't recommend that you do either.  /usr/local is
more traditional and if you like to keep apps contained within their own
package directories then use GNU Stow and install each package as
/usr/local/stow/<package>.  See
<http://www.gnu.org/software/stow/stow.html>

p.s. I passed the LPIC Level 1 exams!  They are tough.

Re: [gentoo-dev] Why the FHS can't be followed

[Luke Ravitch]

On 2002-07-02 15:19, Fuper <futurist@directvinternet.com> wrote:
> The FHS _has_ been followed by Gentoo.

Our /usr directory has lots of stuff that, according to the FHS,
doesn't belong there.  E.g., some packages (at least Octave and
TeXmacs) put stuff in /usr/libexec when the standard dictates
application-based subdirectories of /usr/lib.  And, of course, the
whole /usr/kde and /usr/qt thing that started this thread.

> I would suggest that everyone actually read the FHS at
> <http://www.pathname.com/fhs/>

A very good idea.

> p.s. I passed the LPIC Level 1 exams!  They are tough.

Congrats!

-- 
Luke

Re: [gentoo-dev] Why the FHS can't be followed

[Peter Ruskin]

On Tuesday 02 Jul 2002 21:06, Luke Ravitch wrote:
> Though I'm generally a big supporter, I think the FHS might be wrong
> on this one.  Gnome and KDE should go under /usr/gnome and /usr/kde.
> I do agree that adding an immediate subdirectory of /usr is not
> something that should be taken lightly.  However, Gnome and KDE are
> significantly entrenched as part of Gentoo that they might warrant an
> X-like exception.

FHS says /usr should be read-only.  Some people are already providing /usr 
over network read-only.  Just think about all of KDE's global 
configuration files in /usr/share/config for RedHat and Mandrake; 
/usr/kde/{2,3}/share/config here.  Well perhaps global configs should be 
served readonly, but on my system they seem to change quite often and 
there's a mess of them (56 files and 3 directories).

My guess is it's probably unworkable.  Now we're unlikely to convince KDE 
developers to put these all in an /etc somewhere (my Mandrake box has 78 
/etc subdirectories already) and I'm quite happy to have the 
/usr/kde/{2,3,4} for now.  However, thinking about the read-only 
requirement, I'd rather see /opt/kde/{2,3,4}.

BTW, posting this from the 'drake box due to hard disk crash on the gentoo 
one.
-- 
Mandrake Linux release 8.2 (Bluebird) for i586
AMD Athlon(tm) XP 1600+	 513MB	 Kernel: 2.4.18-6mdk-pnr-win4lin
KDE: 3.0.1		 Qt: 3.0.4	 up 5 hours 18 minutes.
~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~

Re: [gentoo-dev] Why the FHS can't be followed

[Terje Kvernes]

Dan Armak <danarmak@gentoo.org> writes:

  [ ... ]

> And since we've come to the conclusion we can't put it in /opt,
> /usr/kde/2,3 (or equivalent) is the only option left. The fhs
> doesn't provide for having more than one version of a package
> installed at a time but we have to do it with qt2/3 and kdelibs2/3
> (and gnome 1.4/2). I prefer that option over 100% FHS compliance.

  very well put, and I wholeheartedly agree.  100% FHS compliance is
  neat, if it would provide a solution for these problems.  since it
  doesn't, one has to look outside the FHS and find a solution that
  causes the least bit of stress.  and this has been achieved with
  Gentoo beyond a shadow of a doubt.  great work! 
 
> End rant mode. I guess I just had leftover frustration stored from
> the time I actually tried to make this work. Maybe we can put a
> version of this in a FAQ somewhere because this isn't the first time
> this question has been asked.  Maybe if that fhs guy saw it he'd
> think twice before blaming us. The fhs just doesn't accomodate
> certain things.

  yup, if anyone is unhappy, make them provide an alternative.

-- 
Terje

Re: [gentoo-dev] gentoo & fhs

[Karl Trygve Kalleberg]

On Mon, 1 Jul 2002, Collins wrote:

> gnome and kde are in the /usr hierarchy instead of the /opt hierarchy
> "where god intended them to be." 

They lived in /opt before, but then that was suddenly very uncool and they
got moved to /usr. The binary packages were mostly allowed to say in
/opt.

It'd be nice to recruit an FHS zealot to handle all these pesky
path-details for us. 

Karl T