commons-dbcp-1.2.2 needs tomcat:6 to perform test, what makes a dependency like test? tomcat:6. Hence, if >=tomcat-6 is masked and test FEATURE enabled, commons-dbcp won't have its dependencies resolved and won't be merged. One can prefix FEATURES="-test" to an emerge command to avoid testing of a particular package, but AFAIK there's no way to avoid testing for a particular package permanently (there is a way for devs through test USE flag, but normal users can't easily use it). Reproducible: Always Steps to Reproduce: 1. Mask >www-servers/tomcat-5.5.99 2. Enable FEATURES="test" 3. Emerge commons-dbcp-1.2.2 Actual Results: dev-java/commons-dbcp won't have its dependencies resolved, and hence won't be merged. Expected Results: Workaround impossible test and merge.
emerge --info: Portage 2.1.4.4 (default-linux/x86/2007.0, gcc-4.1.2, glibc-2.6.1-r0, 2.6.23-gentoo-r6 i686) ================================================================= System uname: 2.6.23-gentoo-r6 i686 Intel(R) Pentium(R) 4 CPU 3.00GHz Timestamp of tree: Mon, 18 Feb 2008 09:18:01 +0000 ccache version 2.4 [enabled] app-shells/bash: 3.2_p17-r1 dev-java/java-config: 1.3.7, 2.1.4 dev-lang/python: 2.4.4-r6 dev-python/pycrypto: 2.0.1-r6 dev-util/ccache: 2.4-r7 sys-apps/baselayout: 1.12.10-r5 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.61-r1 sys-devel/automake: 1.5, 1.10 sys-devel/binutils: 2.18-r1 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.24 virtual/os-headers: 2.6.23-r3 ACCEPT_KEYWORDS="x86" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=i686 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/terminfo /etc/udev/rules.d" CXXFLAGS="-O2 -march=i686 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="ccache collision-protect distlocks metadata-transfer parallel-fetch sandbox sfperms strict stricter test unmerge-orphans userfetch" GENTOO_MIRRORS="http://ftp.udc.es/gentoo/ http://mirror.ovh.net/gentoo-distfiles/ http://darkstar.ist.utl.pt/gentoo/ http://distfiles.gentoo.org" LANG="es_ES.UTF-8" LC_ALL="es_ES.UTF-8" LINGUAS="es en" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="acl apache2 bash-completion berkdb bitmap-fonts bzip2 caps cli cracklib crypt doc dri fortran gdbm iconv isdnlog midi mudflap ncurses nls nptl nptlonly openmp pam pcre pppd python readline reflection session spl sse2 ssl tcpd threads truetype-fonts type1-fonts unicode vim-syntax x86 xorg zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="es en" USERLAND="GNU" VIDEO_CARDS="apm ark chips cirrus cyrix dummy fbdev glint i128 i740 i810 imstt mach64 mga neomagic nsc nv r128 radeon rendition s3 s3virge savage siliconmotion sis sisusb tdfx tga trident tseng v4l vesa vga via vmware voodoo" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
I forgot to say that there's a kind of related bug on this topic: Bug #205245; it talks about circular dependencies with commons-dbcp-1.2.2 and tomcat-6.
Since tomcat-6.x is not masked in tree. This seems like a local issue. If you mask packages, and then have problems because of such. That is a local issue. Don't mask the package, and or don't set the test use flag. We will be working the circular dep bug, but this doesn't seem like a bug. Since it doesn't exist unless the user does something abnormal locally. Masking tomcat-6.x I do not consider normal. Commenting for now, will likely close as invalid later.
(In reply to comment #3) > Since tomcat-6.x is not masked in tree. This seems like a local issue. If you > mask packages, and then have problems because of such. That is a local issue. > Don't mask the package, and or don't set the test use flag. > The problem is that test isn't a use flag that can be activated or disactivated for each individual package, but a feature that is globally enabled or disabled. It is true that a test use flag exists and is described in use.desc, however, as its description says: test - Workaround to pull in packages needed to run with FEATURES=test. Portage-2.1.2 handles this internally, so don't set it in make.conf/package.use anymore What I was looking for with this bug was a way to disable testing *only* for commons-dbcp, while keeping it for all other packages. On the other hand, I wouldn't personally mind installing Tomcat-6; however, we still use Tomcat-5.5 and wanted to avoid the overload implied in an unnecessary installation.
(In reply to comment #4) > > On the other hand, I wouldn't personally mind installing Tomcat-6; however, we > still use Tomcat-5.5 and wanted to avoid the overload implied in an unnecessary > installation. > Then just package.mask >=www-servers/tomcat-6?
(In reply to comment #4) > > The problem is that test isn't a use flag that can be activated or disactivated > for each individual package, but a feature that is globally enabled or > disabled. Yes, so more than likely you need to disable it globally. There is no benefit really and it's mostly used for us when testing an ebuild for version bumps, different jdks, stabilization, etc. > What I was looking for with this bug was a way to disable testing *only* for > commons-dbcp, while keeping it for all other packages. Seems more like you should disable testing globally. What benefit are you getting by having that enabled. Aside from slower merges? > On the other hand, I wouldn't personally mind installing Tomcat-6; They are slotted, so it's not a matter of one or the other. Both can coincide and there is no problems there. however, we > still use Tomcat-5.5 and wanted to avoid the overload implied in an unnecessary > installation. > Based on this entire bug being unique to you and your env. Based on how you all are choosing to do things. I am going to close this as invalid, because it's not something I can address in tree. Nor something other users are running into. Local issues, self inflicted. If you feel portage should have ability to disable FEATURE=test on certain packages. Then file a bug accordingly, but that will be portage specific.
(In reply to comment #6) > > If you feel portage should have ability to disable FEATURE=test on certain > packages. Then file a bug accordingly, but that will be portage specific. > Such a bug most likely exist already. This can already be done using bashrc.
(In reply to comment #5) > > Then just package.mask >=www-servers/tomcat-6? > That's what I did and William L. Thomson Jr. thought was abnormal. (In reply to comment #6) > > Seems more like you should disable testing globally. What benefit are you > getting by having that enabled. Aside from slower merges? Taken from man make.conf: test Run package-specific tests during each merge to help make sure the package compiled properly. See test in ebuild(1) and src_test() in ebuild(5). This feature implies the "test" USE flag. Well, making sure a package has been compiled properly is a good enough reason for me to enable testing, sorry you don't agree. > > > On the other hand, I wouldn't personally mind installing Tomcat-6; > > They are slotted, so it's not a matter of one or the other. Both can coincide > and there is no problems there. > True, but still I don't feel comfortable with installing a package I don't need at all, nor will I use it. > however, we > > still use Tomcat-5.5 and wanted to avoid the overload implied in an unnecessary > > installation. > > > > Based on this entire bug being unique to you and your env. Based on how you all > are choosing to do things. I am going to close this as invalid, because it's > not something I can address in tree. Nor something other users are running > into. Local issues, self inflicted. > > I would rather say it's based on how you want us all to do things, but I won't run into that. Clearly there's one single valid opinion, yours, and I'll have to accept it.
(In reply to comment #8) > (In reply to comment #5) > > > > Then just package.mask >=www-servers/tomcat-6? > > > > That's what I did and William L. Thomson Jr. thought was abnormal. Petteri didn't realize that's what created the problem in the first place. > Well, making sure a package has been compiled properly is a good enough reason > for me to enable testing, sorry you don't agree. That is also a job of our arch testers when we stabilize a package. Test are mainly used by devs during version bumps, testing with various jdks, etc. Then again by arch testers. The chances of a test failing on a stable package is not to likely. But surely possible. Put another way, have you had any benefit from running FEATURES=test? Has it caught anything that you would have not before. I think it's giving you a false sense of security. Plus any compile time issue, is usually seen during compile. Like with a failed compile or etc. Test wrt to Java mostly test runtime things, and that the code does what it was intended. > > True, but still I don't feel comfortable with installing a package I don't need > at all, nor will I use it. commons-dbcp needs it for it's tests. So you do need it indirectly. And commons-dbcp tests will use it. > I would rather say it's based on how you want us all to do things, but I won't > run into that. Clearly there's one single valid opinion, yours, and I'll have > to accept it. That's taking things a bit to far. You just can't have your cake and eat it to. I am not forcing any particular route on you. You have several options. You can not mask tomcat-6. Or not set FEATURES=test. It's your unique combo of doing both creates your problem. It's not my fault or preference, that you don't want tomcat-6 to be installed. Sure we could possible allow commons-dbcp to use either tomcat 5.5 or tomcat 6. But that's extra work, and likely a pita. Since it would be a nested USE flag. Only activated or not when FEATURES=test is set. It's more like you want us to fix things based on how you want to do things. Which is fine if you want put effort forth into making that a reality. But for me to spend my time making changes for a one off situation. I just can't justify. It's not my way or etc, it's the general consensus. Would any other users benefit? For you to take the stance that we are forcing you to do things our way. Isn't to friendly. You are welcome to make it your way, by donating your time :)
You can disable features per package, put: FEATURES="-test" in /etc/portage/env/dev-java/commons-dbcp Although I'm not sure that this will affect also USE=-test for dependency resolution. Maybe accompanied by a "dev-java/commons-dbcp -test" entry in /etc/portage/package.use. If that doesn't work maybe it's considerable as portage bug - user should be able to override USE=test trigerred by FEATURES=test (check for dupes though). Hm or maybe the user-set USE="-test" should imply FEATURES="-test" itself. It would make the implication sound :)
(In reply to comment #9) > ... Well, I guess it's not a question of right or wrong, just ways of working. And, although an argument can be stated and a debate created to discuss the best way to do things, I shouldn't have used the terms I chose to use; I must admit that I ranted rather than argued, and that rarely helps. I thought I had taken a good choice with my combo and I'll try to keep it that way, but still I'll consider changing it for good. My apologies.
