Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 106693 - /etc/apache/modules/modules wrong destination
Summary: /etc/apache/modules/modules wrong destination
Status: RESOLVED WORKSFORME
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Apache Team - Bugzilla Reports
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-09-20 09:30 UTC by David D. Huff Jr.
Modified: 2005-11-05 09:46 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 David D. Huff Jr. 2005-09-20 09:30:04 UTC
current apache ebuild places .so modules in wrong directories.
s/b /etc/apache/modules/
not /etc/apache/modules/modules

Reproducible: Always
Steps to Reproduce:
1.emerge apache
2.
3.

Actual Results:  
places .so modules in /etc/apache/modules/modules

Expected Results:  
place .so modules in /etc/apache/modules
Comment 1 Michael Stewart (vericgar) (RETIRED) gentoo-dev 2005-09-20 13:45:12 UTC
Please provide more details.
We need the exact version of apache you are using, and what exactly is being put
in /etc/apache2/modules/modules.
Comment 2 David D. Huff Jr. 2005-09-20 14:01:50 UTC
all so modules are being put into the wrong directory. The version is
apache-1.3.33-r12
httpd.exp         mod_auth_dbm.so     mod_headers.so      mod_rewrite.so
libphp4.so        mod_auth_digest.so  mod_imap.so         mod_setenvif.so
libproxy.so       mod_autoindex.so    mod_include.so      mod_speling.so
libssl.so         mod_cern_meta.so    mod_info.so         mod_status.so
mod_access.so     mod_cgi.so          mod_log_agent.so    mod_throttle.so
mod_actions.so    mod_digest.so       mod_log_config.so   mod_unique_id.so
mod_alias.so      mod_dir.so          mod_log_referer.so  mod_userdir.so
mod_asis.so       mod_env.so          mod_mime.so         mod_usertrack.so
mod_auth.so       mod_example.so      mod_mime_magic.so   mod_vhost_alias.so
mod_auth_anon.so  mod_expires.so      mod_mmap_static.so
mod_auth_db.so    mod_gzip.so         mod_negotiation.so
Comment 3 Michael Stewart (vericgar) (RETIRED) gentoo-dev 2005-10-22 14:31:21 UTC
I'm puzzled by this one. On my system the modules are placed in the correct
location (/usr/lib/apache/modules) If you get time, can you see if you can trace
down where exactly in the ebuilds/eclass this is going wrong? There shouldn't
even be binaries in /etc.
Comment 4 David D. Huff Jr. 2005-10-22 19:56:23 UTC
Your answer was silly. The symlink is what was incorrect. I don't think you
really know how it is supposed to work, never mind.
Comment 5 Jakub Moc (RETIRED) gentoo-dev 2005-10-23 03:49:52 UTC
(In reply to comment #4)
> Your answer was silly. The symlink is what was incorrect. I don't think you
> really know how it is supposed to work, never mind.

It would be nice if you could finally provide some useful information instead of
flaming. I have no clue what symlink are you talking about (looks like your
local cruft, not anything created by ebuilds/eclasses).
Comment 6 David D. Huff Jr. 2005-10-23 09:47:49 UTC
No, I'm not going to let this drop now. I had three servers that go down over
this! Something in the changed to cause this, you're just writing it off because
I can't give you a more defined answer, If I knew I MIGHT TELL YOU OUT OF THE
KINDNESS OF MY HEART. These systems configuration had not been changed in three
years and blam! All three of them and this symlink issue. Fine! If you don't
know what changed or why it happened the say so.

I'm damned tired of being dissed by gentoo people because of changes they make
that cause failures.

There is a huge difference between flaming and holding people accountable to the
changes they make that affect others. 

Even if I was the only person with this problem, I am still affected and just as
important. 
Comment 7 Bryan Østergaard (RETIRED) gentoo-dev 2005-10-23 11:01:50 UTC
David, we really can't help you as long as you don't tell us what this symlink
is.  I'm sure we'll be able to help you if you just provide the information we
ask for.

Also, you might want to read http://www.gentoo.org/doc/en/apache-upgrading.xml.
Comment 8 Michael Stewart (vericgar) (RETIRED) gentoo-dev 2005-10-23 15:09:20 UTC
(In reply to comment #4)
> Your answer was silly. The symlink is what was incorrect. I don't think you
> really know how it is supposed to work, never mind.

I am not sure what you mean by this. I am the apache maintainer - I'm the one
that designs how apache works on Gentoo. If you have symlinks in /etc/ for
apache, then your system is really really broken, or possibly quite outdated
(several years ago a former apache maintainer had symlinks in /etc, but those
went away at least 2 years ago). Gentoo doesn't update itself, you have to take
care of it. We can't possibly test for every possible upgrade path for every
user that is 3 years out of date. We test from most recent release to current
for upgrade paths. Your breakage was your own fault due to not keeping your
systems up to date.
Comment 9 David D. Huff Jr. 2005-11-05 09:46:03 UTC
Thank you for the proof I needed. Thanks to your moronic assumptions I do now
know that you don't know what you are talking about.

Because apache had been updated on my system for the three years you claim it
wasn't. In fact apache-1.3.33-r5 had been running on my systems when
apache-1.3.33-r6 broke it.

You want everybody to remove outstanding cruft fine, how the hell was I supposed
to know it was cruft when it worked all along?

Fine I'll get the new system working until you guys break it again. Get over
yourselves your assumptions worse than incorrect they are arrogant.