Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 33476 - binaries in /etc (xfree and apache ebuilds)
Summary: binaries in /etc (xfree and apache ebuilds)
Status: RESOLVED WONTFIX
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All Linux
: High enhancement (vote)
Assignee: Gentoo X packagers
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-11-14 12:56 UTC by Peter Simons
Modified: 2004-04-05 12:05 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Peter Simons 2003-11-14 12:56:27 UTC
The xfree package copies (and links) several configuration files from the X11
package into /etc/X11, what is fine, IMHO. But it also copies (and links)
several executable programs into /etc/X11 as well, and I'm not sure this is a
good idea. At least on my system, /etc is version-controlled, and binaries cause
nothing but trouble here. IMHO executables don't belong into /etc, so I wonder,
whether it would be possible to change the ebuild to be a bit more selective
about what to copy/link to /etc/X11 and what not?

Oh, the same thing applies to the apache package (1.x and 2.x), which goes as
far as linking *shared* *libraries* into /etc/apache, what really makes no
sense, IMHO.

Generally, I think that a system without a *single* symlink is best, and since
Gentoo builds everything from the source, I really don't see why excessive
symlinking would be necessary at all.

Just my 0.02 Euros ...

Reproducible: Always
Steps to Reproduce:
Comment 1 SpanKY gentoo-dev 2003-11-14 13:33:20 UTC
it is done because it is a LOT easier than trying to split up the package
Comment 2 Peter Simons 2003-11-14 13:46:23 UTC
I'm sure it makes things much easier for the maintainers, and I know I'm in no position to complain, since I'm paying nothing your your guys work at all, but nonetheless, binaries IMHO shouldn't be located in /etc. It's just wrong.

Maybe these files could be moved somewhere else step-by-step? Like, /usr/libexec/gentoo/ or whatever? As it is, versioning the machine's configuration is almost impossible, because CVS, darcs, and many other VC tools choke an binaries and I have almost corrupted my installation twice now because of this. I'm sure other people have the same problem -- or will have it.

By the way: This applies to the apache ebuild far more than to X11, which is quite moderate in what it puts in /etc. The apache 2.x build places virtually *all* of the package in /etc/apache!
Comment 3 Donnie Berkholz (RETIRED) gentoo-dev 2003-11-14 14:02:36 UTC
IRT xfree: it largely does things for backwards and/or cross-platform compatibility. FHS actually has some more info on how and why as well.
Comment 4 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2003-11-14 16:45:10 UTC
The apache1/2 symlink stuff exists because of how apache expects paths to it's file.
Firstly, you specify ServerRoot, and it takes all relative paths in relation to that ServerRoot.

Relative paths are used for:
configuration files
logs
modules

True, we could specify absolute paths to all of those items, but it would definetly make things less readable and more difficult to maintain.

The one other possible solution
is to make a new directory, say /usr/libexec/apache-${PV}/ and put the symlinks in there, and designate that as the ServerRoot. That would then symlink over to the configuration files in /etc/apache2/conf
Comment 5 Peter Simons 2003-11-15 10:19:12 UTC
I agree that adding those symlinks makes it easier for the maintainers of the package, but I don't think it makes it easier for the *users* at all. Just the opposite: It's very, very confusing to read path A, which is, in fact, a link to B, which contains a config file pointing to C, which is a link to D. I'm sure you catch my drift. :-)

If you don't know apache v2 -- and I don't --, the installation as-is is pretty much incomprehensible, which caused me to file this request in the first place!

IMHO, having concrete, full paths all over the config files -- and no symlinks at all -- would be in the best interest of the users. (Albeit more complicated for the maintainers, I agree.) Or you might consider installing apache the way it wants to be installed per default: to /usr/local/apache2. This way, you won't have to tweak the file paths as much as you have to when putting it into the flat directory hierarchy. /usr/libexec/apache-$PV is just the same thing, IMHO, but less obvious than the default location of the package.

As for X11: I wonder how many package would actually break if the symlinked stuff in /etc/X11 would be gone. As far as I can tell, virtually everybody uses /usr/X11R6/ as the prefix for all things X11'ish in his/her programs. I have never seen an /etc/X11 path hardcoded into a program yet. Putting the config files to /etc/X11 is fine, IMHO, but for the binaries, I don't think it's really necessary. I for one would be willing to help debug a package that tries to get along without these links. ;-)
Comment 6 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2004-01-17 03:52:04 UTC
ServerRoot is moved to /usr/lib/apache2 as of apache-2.0.48-r2 and users are instructed to remove the old symlinks in /etc/apache2.

leaving this for the X people now.
Comment 7 Peter Simons 2004-01-17 06:45:38 UTC
Great guys, thanks a lot!
Comment 8 David M. Andersen 2004-01-18 19:53:00 UTC
If the layout confuses you, just do this:

tree -AC /etc/apache | less

The output is downright *beautiful*. :-)

tree is in app-text/tree.
Comment 9 Peter Simons 2004-02-05 04:59:09 UTC
 > I'd say the answer to that is historical reasons.

You missed my point: I wanted to illustrate how the
distinction between "config files" and "databasa data" is
completely arbitrary, IMHO. 


 > You can use tools to update these files.

So what? I can use tools to update pretty much _any_ file on
the hard disc. That's not a special property of master zones
files. (And BTW: Dynamic DNS do not change the zone files,
the changes are kept in separate journal files, which you
should, I agree, place in /var.)

My point is that a master zone file is absolutely not the
same thing as an deferred e-mail in /var/spool/mqueue. It
will not go away after a time-out, it will not be modified
by BIND, and BIND will not be able to start-up properly,
when it's missing. 


 > Really sorry to sound harsh [...]

Don't worry about sounding harsh. We're all on the same
side, right? :-) Just say what you think, do the same. 


 > why should the distro care what you specfically want?  

I'm trying to explain why there are good reasons for my
preferred directory layout. If you don't agree, well, then
that's fine. I know how to change the paths. We are arguing
about something that's a matter of taste, not a matter of
fact. I can distinguish between those two concepts.


 > The right thing(tm) [is IMHO] to follow the FHS.

I personally don't care much for the FHS. I'll follow it
where it makes sense and I'll ignore it when it doesn't.
Besides, I don't think your interpretation of the FHS
applies to DNS master zone files.


 > [That] idea breaks down if you have any databases using
 > config files stored in /etc/.  

I don't think I understand that statement.


 > Or what about apache? 

I don't see how Apache has anything to do with this matter.
Besides, you might want to look at #33476 for proof that I'm
not advocating to put everything into /etc at all. On the
contrary. :-)


 > I see what you would like to do, but the problem is your
 > solution would be limited, and improper in many situations.  

I have been running BIND that way for several years and I
have never found the solution to be "improper". Could you
give a concrete example, where having the master zone files
in /etc causes problems?
Comment 10 Peter Simons 2004-02-05 05:01:59 UTC
Aaargh. Sorry, but I accidently pasted my reply for bug #34886 into the wrong window. :-( :-( Could someone remove reply #9 -- and #10 -- from this bug?
Comment 11 Peter Simons 2004-04-05 08:58:20 UTC
Is there still any interest in this bug report? Unless I hear something, I'll close it any time soon, OK?
Comment 12 Donnie Berkholz (RETIRED) gentoo-dev 2004-04-05 12:05:23 UTC
X won't be changing, and it seems apache people have removed themselves.