I was forced to install gentoo-webroot with the new version of apache released. When I did, by existing index.html in /var/www/localhost/htdocs was overwritten with the Gentoo default. Reproducible: Always Steps to Reproduce: 1. emerge gentoo-webroot-default 2. 3. Actual Results: My index.html overwritten with Gentoo's index.html Expected Results: It should not replace files that already exist in the webroot. qbranch ~ # emerge info Portage 2.0.51-r15 (default-linux/amd64/2005.0, gcc-3.4.3, glibc-2.3.4.20050125-r0, 2.6.10-gentoo-r7 x86_64) ================================================================= System uname: 2.6.10-gentoo-r7 x86_64 AMD Athlon(tm) 64 Processor 3500+ Gentoo Base System version 1.6.9 Python: dev-lang/python-2.3.5 [2.3.5 (#1, Feb 18 2005, 16:45:58)] distcc 2.18.3 x86_64-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] dev-lang/python: 2.3.5 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.5, 1.9.4, 1.6.3, 1.4_p6, 1.8.5-r3, 1.7.9-r1 sys-devel/binutils: 2.15.92.0.2-r2, 2.15.92.0.2-r4 sys-devel/libtool: 1.5.10-r5 virtual/os-headers: 2.6.10 ACCEPT_KEYWORDS="amd64 ~amd64" AUTOCLEAN="yes" CFLAGS="-march=athlon64 -mtune=athlon64 -O2 -fomit-frame-pointer -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/config /var/qmail/alias /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=athlon64 -mtune=athlon64 -O2 -fomit-frame-pointer -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.namerica.gentoo.org/gentoo-portage" USE="amd64 X aalib acpi alsa apache2 arts avi bitmap-fonts bonobo cdr crypt cups curl dba divx4linux dvd dvdr dvdread esd f77 fam flac foomaticdb fortran gd gdbm gif gimpprint gnome gpm gstreamer gtk gtk2 gtkhtml guile imagemagick imap imlib innodb ipv6 java jit joystick jp2 jpeg kde kdeenablefinal ldap libwww lzw lzw-tiff mad mikmod motif mozilla mpeg mysql ncurses nls nptl offensive oggvorbis opengl oss pam pdflib perl png ppds python qt quicktime readline rtc samba sdl session slang sockets softmmu spell ssl svg tcpd tiff truetype truetype-fonts type1-fonts usb userlocales xml xml2 xmms xpm xrandr xv xvid zlib" Unset: ASFLAGS, CBUILD, CTARGET, LANG, LC_ALL, LDFLAGS
Enabled the no-htdocs USE flag for gentoo-webroot-default, as per http://dev.gentoo.org/~vericgar/doc/apache-package-refresh.html in the description of the USE flags. This USE flag was created because of this very issue.
Either that flag is counterintuitive (it should be 'enable-htdocs' or something alike) or the ebuild is faulty, as it should check for a pre-existent document anyway. Probably both. Either way, I do not believe this is a sane default, and I can't see how could this be ever put into x86 without unleashing hell. As you may certainly know (I hope you're with me in this one) seeing people on the street without a "please-don't-hit-me" tatto on their foreheads does not make attacking them any less wrong.
What is stopping a check to see if /var/www/localhost/htdocs/index.html already exists? People upgrading from an older version of apache are not given any warning that their site is about to be overwritten (perhaps the build should fail unless an enable-htdocs eflag is set, as Ch.P. suggested). I'm lucky I had nightly backups... others will not be as lucky.
It was done the way it is now because the default is how it used to be done - backwards compatibility - and then enabling the USE-flag enables the feature of not overwriting /var/www/localhost The problem with checking to see if the files are already there is the package is more then one file... it will be (eventually) a complete gentoo-themed iconset, error documents, and default virtual host (localhost). The comparing this example to wearing a sign on the street isn't really valid, as any sane person checks what they are about to do (--pretend or --ask) before actually updating... and if you use --verbose emerge tells you all the effected USE-flags... users should check to see what USE-flags mean in /usr/portage/use.* if they are unsure, and then set them appriately in /etc/portage/package.use or /etc/make.conf.
I can guarantee that many people will have problems with the upgrade, and I can guarantee that those same people are the people who do not back up their stuff. Yes, I'm saying that I'm careless while upgrading (this probably means that I shouldn't be running ~arch, but I do anyway), and I admit that I should have been more careful. I ran an emerge -uDp world first to check which packages needed to be upgraded. I saw there was an apache upgrade, so I ran emerge apache and left to do something else. I did not notice the gentoo-webroot-default package. I came back to find my index.html overwritten... I'm not that familiar with how etc-update works, but could the stuff that the gentoo-webroot-default package installs not be called "configuration" files, so that they would only be updated when etc-update is run? I don't really care whether this bug is fixed or ignored... I've been stung by it once, bought the tshirt, and fixed my use flags. I decided that this was unexpected behaviour, and filed a bug for it. I mean, what sane application overwrites user data without even prompting them first? Anyway, I am sure that by not fixing this bug, though, that a lot more people will suffer the same problem I did. I'm all for preventing people from getting pissed off!
/var/www/localhost isn't supposed to be user data, it's supposed to be where apache installs it's default icons and error documents, and a "It works!" webpage. Then the user is supposed to create virtual hosts beside that directory - virtual hosts that are never touched by any package. We added the no-htdocs USE flag because there are a subset of users that insist on installing thier website into the default webroot. Before this most recent update, the no-htdocs option wasn't even available. We catered to this subset of users that don't like the default, but the default is still the default, and you have to enable a USE flag to get non-default settings.
I was not aware that this was the default... this is the first time that my index.html file has been overwritten. I have been running Gentoo with apache installed and my site in localhost/htdocs since November 2003. Genlop says that I have installed apache six different times since building this box (October 2004, amd64). It doesn't make sense for me to run virtual hosts on this box, as I only run one site. Anyway, I'll stop complaining now. I've made my points, and you've made yours. It's clear that this behaviour isn't going to change.
I am aware the comparison was offtopic, but as a rational person does indeed check what it is doing, a sane package should do the same. If index.html already exists, why overwrite it? 1) If it is an older version of the 'it works!' message, updating it isn't a priority (not in my book, anyway). 2) If it is not the welcome message (the only other possibility, if my logic is not all that faulty), then overwriting it is almost certainly harmful. Q) So what kind of functionality is gained with this default? Also, older updates never did overwrite index.html, as Chris Kloosterman noted. And this was a -r2 to -r3 update; I know what I do is to look at the version bump in my emerge -upDv world. I did that and inferred a release update couldn't be harmful; I know I was mistaken, but perhaps other people will think the same.
"and then enabling the USE-flag enables the feature of not overwriting /var/www/localhost" The "enables the feature of not" part of the statement just proved that the no-htdocs flag is counterintuitive. This should be replaced by a "htdocs" USE flag that is disabled by default. Manually enabling this "htdocs" USE flag enables the feature of overwriting /var/www/localhost. You said that 1) users should use --pretend or --ask 2) users should use --verbose 3) users should check what the USE flags mean 4) users shouldn't store data at /var/www/localhost I just want to say that 1) portage shouldn't surprise the users By the way, you misplaced the location of use.*, yet you fully expect users to know where these files are. And even if users follow your 1, 2, and 3, it is rather easy to overlook some USE flags especially when updating several packages at the same time. RIP to my 20-liner index.html
First, we created this ebuild for having a common /var/www/localhost for all the web servers being supported by Gentoo. Second, we keep backwards compatibility (as already said), that is, we still continue to write webroot default stuff to /var/www/localhost. However, on an emerge --update, why this didn't overwrite your user defined data in /var/www/localhost/htdocs but it obviousely does now is maybe a portage bug because it took care about your user defined data (md5-old != md5-new) as long as the the new installed data comes just from an ebuild update (FOO-1.1 to FOO-1.2 e.g.) but appearently doesn't care about now since the corresponding ebuild for /var/www/localhost has changed from apache to gentoo-webroot-default. Though, you may not experience this behavior on next gentoo-webroot-default update ;-) Third, the no-htdocs MAY BE counter-intuitive with respect to the percentage of FOO useflags against the NO_FOO useflags. However, we SHALL keep backwards compatibility (as said, again), that is, keeping it as is. The intentional idea of gentoo-webroot-default has been already greatly defined somewhere above. However, what I propose, is, to make the Apache default virtual host to an <IfDefine DEFAULT_VHOST> section, just like we did with the modules. So, the enduser/admin can still have just a single host configured apache or even define its own default virtual host.
I remember I saw a link in some recent GWN pointing to a hot discussion why imbiguous negative use flags are evil. This pretty much proves the point.
Uhm, no.. That pretty much sums up what _some_ developers think about no- USE flags. There are at least three watching this bug that think differently.
*** Bug 95009 has been marked as a duplicate of this bug. ***
