emerge -av eclean-kernel These are the packages that would be merged, in order: Calculating dependencies / !!! Problem resolving dependencies for app-admin/eclean-kernel ... done! !!! The ebuild selected to satisfy "eclean-kernel" has unmet requirements. - app-admin/eclean-kernel-0.3::gentoo USE="(multilib)" PYTHON_TARGETS="-python2_6 -python2_7" The following REQUIRED_USE flag constraints are unsatisfied: any-of ( python_targets_python2_6 python_targets_python2_7 ) This effectively blocks all other emerges .. setting PYTHON_TARGETS="python2_7" or PYTHON_TARGETS="python2_6 python2_7 python3_2" or some other variation in /etc/make.conf or preceeding emerge on the command line allows all emerges to proceed Reproducible: Always emerge --info Portage 2.1.10.59 (default/linux/amd64/10.0, gcc-4.5.3, glibc-2.15-r1, 3.3.4-gentoo x86_64) ================================================================= System uname: Linux-3.3.4-gentoo-x86_64-Intel-R-_Core-TM-2_Duo_CPU_T5870_@_2.00GHz-with-gentoo-2.1 Timestamp of tree: Sat, 12 May 2012 12:35:01 +0000 app-shells/bash: 4.2_p28 dev-java/java-config: 2.1.11-r3 dev-lang/python: 2.7.3-r2, 3.2.3-r1 dev-util/cmake: 2.8.8-r2 dev-util/pkgconfig: 0.26 sys-apps/baselayout: 2.1 sys-apps/openrc: 0.9.9.3 sys-apps/sandbox: 2.5 sys-devel/autoconf: 2.13, 2.69 sys-devel/automake: 1.10.3, 1.11.5 sys-devel/binutils: 2.22-r1 sys-devel/gcc: 4.5.3-r2 sys-devel/gcc-config: 1.7 sys-devel/libtool: 2.4.2 sys-devel/make: 3.82-r3 sys-kernel/linux-headers: 3.3 (virtual/os-headers) sys-libs/glibc: 2.15-r1 Repositories: gentoo derk-personal ACCEPT_KEYWORDS="amd64 ~amd64" ACCEPT_LICENSE="* -@EULA" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-O2 -pipe" DISTDIR="/usr/portage/distfiles" EMERGE_DEFAULT_OPTS="--autounmask --autounmask-write --quiet-build=y" FEATURES="assume-digests binpkg-logs distlocks ebuild-locks fixlafiles news parallel-fetch parse-eapi-ebuild-head protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox" FFLAGS="" GENTOO_MIRRORS="http://distfiles.gentoo.org" LANG="en_US.utf8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" LINGUAS="en en_GB en_US" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/home/derk/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X acl alsa amd64 apng archive berkdb bzip2 cairo cdda cddb cdr cli cracklib crypt cups cxx dbus dri dvd dvdr encode ffmpeg flac fortran fuse gallium gdbm gnutls gphoto2 gpm gstreamer gtk iconv id3tag ipv6 jpeg jpeg2k lame lcms libnotify mad mmx modules mp3 mpeg mudflap multilib ncurses nls nptl ntp ogg opengl openmp pam pcre pdf pm-utils png policykit ppds pppd qt4 readline scanner sdl session sna sse sse2 ssl startup-notification svg tcl tcpd theora tiff tk twolame unicode v4l vorbis vpx wav webm x264 xcb xinerama xorg zlib" ALSA_CARDS="hda-intel intel8x0 intel8x0m" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul 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 cgi cgid 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" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump" CAMERAS="*" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" INPUT_DEVICES="evdev synaptics wacom" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LINGUAS="en en_GB en_US" PHP_TARGETS="php5-3" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="intel vesa fbdev" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CPPFLAGS, CTARGET, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON
if eclean-kernel-0.3 is installed it still requires PYTHON_TARGETS to be set properly ... else it blocks any emerges if you had an earlier version installed then the update blocks the emerges until Python_targets is set.. How would one set the environment just for this package in /etc/portage/package.env ?
okay created in /etc/portage/env/eclean-kernel containing the line: PYTHON_TARGETS="python2_7 python3_2" created in /etc/portage/package.env/eclean-kernel containing the line: app-admin/eclean-kernel eclean-kernel and all is well ..
jer@wieneke /newaches/gentoo/cvs/gentoo-x86/app-admin/eclean-kernel $ ebuild eclean-kernel-0.3.ebuild install Appending /newaches/gentoo/cvs/gentoo-x86 to PORTDIR_OVERLAY... The following REQUIRED_USE flag constraints are unsatisfied: || ( python_targets_python2_6 python_targets_python2_7 )
This is a regular USE_EXPAND to be set in make.conf. I am not the person who can do it for you. @Python, @portage: can we make this switch a little more friendly to users?
This is going to get tricky when new/unstable versions of python come out. The package.stable proposal is supposed to help for similar issues: http://archives.gentoo.org/gentoo-pms/msg_0aa9148d070b54ba913debd9279b7351.xml However, it seems like we'd also need a use.stable file in order to tweak default USE settings for the stable users.
What was wrong with using eselect python to get/set this information as other packages do?
Per discussion on ml: just do it.
(In reply to comment #6) > What was wrong with using eselect python to get/set this information as > other packages do? There is no way to call eselect python from make.conf or a profile. The use flags need to be set before the ebuild/eclass code is invoked.
(In reply to comment #7) > Per discussion on ml: just do it. I will make the change in the base profile tomorrow.
(In reply to comment #8) > (In reply to comment #6) > > What was wrong with using eselect python to get/set this information as > > other packages do? > > There is no way to call eselect python from make.conf or a profile. The use > flags need to be set before the ebuild/eclass code is invoked. But surely there is a way for eselect to set PYTHON_TARGETS.
(In reply to comment #10) That's a nice thought, but not a very simple thing to implement. There are a couple of ways I can think of: 1. Modify portage configuration (/etc/make.conf). 2. Set PYTHON_TARGETS in an env.d file, which would override the portage config. I don't really like the idea of modifying make.conf from an eselect module. I'm also not sure how we could allow the user to override eselect python for cases where more than one version of python-2 and python-3 are desired.
(In reply to comment #11) How about letting eselect python to write env.d file with PYTHON_TARGETS, which then could be owerriden by user in make.conf and there they could put as many targets as they wish (or combine env.d setting with make.conf). Zac would know better if emerge could work with it that way.
(In reply to comment #12) > How about letting eselect python to write env.d file with PYTHON_TARGETS, > which then could be owerriden by user in make.conf and there they could put > as many targets as they wish (or combine env.d setting with make.conf). Zac > would know better if emerge could work with it that way. Yeah, that would work because USE_ORDER (see `man make.conf`) includes env.d. It's kind of ugly though, because the variables from env.d are also exported in your shell. That mean you need to make sure to source /etc/profile after any updates, in order to avoid inconsistencies between the env.d settings and your current shell settings, because USE_ORDER also includes env (your exported shell variables).
(In reply to comment #12) > (In reply to comment #11) > > How about letting eselect python to write env.d file with PYTHON_TARGETS, > which then could be owerriden by user in make.conf and there they could put > as many targets as they wish (or combine env.d setting with make.conf). Zac > would know better if emerge could work with it that way. I don't think that makes sense - New major Python releases are not that common, so updating your make.conf shouldn't be a big issue.
I tried setting PYTHON_ABIS in env.d file about 1 year ago and I recommend to not use env.d files due to unreliable and unintuitive behavior.
(In reply to comment #14) > I don't think that makes sense - New major Python releases are not that > common, so updating your make.conf shouldn't be a big issue. It is not a big issue. But it is an inconvenience. Eselect is for selecting between alternatives, so I think that should be used for the sake of consistency.
(In reply to comment #16) > (In reply to comment #14) > > I don't think that makes sense - New major Python releases are not that > > common, so updating your make.conf shouldn't be a big issue. > > It is not a big issue. But it is an inconvenience. Eselect is for selecting > between alternatives, so I think that should be used for the sake of > consistency. Consistency? With what? Which other USE_EXPAND has an eselect module that updates /etc/make.conf?
(In reply to comment #17) > Consistency? With what? Which other USE_EXPAND has an eselect module that > updates /etc/make.conf? It's just a common user expectation that their eselect configurations should be "respected" by all Gentoo things. An example is bug 283587.
(In reply to comment #17) > Consistency? With what? Which other USE_EXPAND has an eselect module that > updates /etc/make.conf? Consisten way for managing alternatives on Gentoo. And the proposition was not to update /etc/make.conf, but set the variable elsewhere using eselect (and allow for override by user).
(In reply to comment #19) > (In reply to comment #17) > > Consistency? With what? Which other USE_EXPAND has an eselect module that > > updates /etc/make.conf? > > Consisten way for managing alternatives on Gentoo. And the proposition was > not to update /etc/make.conf, but set the variable elsewhere using eselect > (and allow for override by user). And consistent way of managing USE is make.conf (& profiles).
(In reply to comment #19) > (In reply to comment #17) > > Consistency? With what? Which other USE_EXPAND has an eselect module that > > updates /etc/make.conf? > > Consisten way for managing alternatives on Gentoo. Let me repeat: what other USE_EXPAND variable has eselect module? > And the proposition was > not to update /etc/make.conf, but set the variable elsewhere using eselect > (and allow for override by user). /etc/make.conf is used to set USE and USE_EXPAND variables, like Michał noted. Lets end the discussion about eselect for USE_EXPAND and focus on the core of this bug: default value of PYTHON_TARGETS.
(In reply to comment #21) > (In reply to comment #19) > > (In reply to comment #17) > > > Consistency? With what? Which other USE_EXPAND has an eselect module that > > > updates /etc/make.conf? > > > > Consisten way for managing alternatives on Gentoo. > > Let me repeat: what other USE_EXPAND variable has eselect module? Frankly, I don't care. As Zac said, I expect to set python versions to use trough eselect and then emerge to respect that. If that can't be done trough USE_EXPAND, then maybe that is the wrong solution for what it tries to do. Are there better solutions? > > > And the proposition was > > not to update /etc/make.conf, but set the variable elsewhere using eselect > > (and allow for override by user). > > /etc/make.conf is used to set USE and USE_EXPAND variables, like Michał > noted. Fair enough. That is, if USE_EXPAND is really unavoidable in this case. IMHO the core of this bug is that new USE_EXPAND has showed up.
(In reply to comment #21) > Lets end the discussion about eselect for USE_EXPAND and focus on the core > of this bug: default value of PYTHON_TARGETS. Yeah, modifying the profile is nice and simple, and I still intend to do it. I just wanted to make sure we consider all of the options.
(In reply to comment #22) > (In reply to comment #21) > > (In reply to comment #19) > > > (In reply to comment #17) > > > > Consistency? With what? Which other USE_EXPAND has an eselect module that > > > > updates /etc/make.conf? > > > > > > Consisten way for managing alternatives on Gentoo. > > > > Let me repeat: what other USE_EXPAND variable has eselect module? > > Frankly, I don't care. As Zac said, I expect to set python versions to use > trough eselect and then emerge to respect that. The problem lies in the above sentence: *you* expect, it doesn't mean that everyone else does. > If that can't be done trough > USE_EXPAND, then maybe that is the wrong solution for what it tries to do. You can try coming up with generic solution for eselect to play with USE_EXPAND - check ${PORTDIR}/profiles/desc for complete list. Please use separate bug for this. > Are there better solutions? Not that I'm aware of. > > > > > And the proposition was > > > not to update /etc/make.conf, but set the variable elsewhere using eselect > > > (and allow for override by user). > > > > /etc/make.conf is used to set USE and USE_EXPAND variables, like Michał > > noted. > > Fair enough. That is, if USE_EXPAND is really unavoidable in this case. IMHO > the core of this bug is that new USE_EXPAND has showed up. I think that USE_EXPAND is best solution at this point.
Just a crazy idea: /etc/make.conf.d/00-python-abi-{2.{6,7,8},3.{1,2}}.conf And use eselect to switch it on/off, as many other eselect's do. eselect makeconf set python-abi-2.6 on/off. It will also has some use for users - like switching particular PORTDIR_OVERLAY's on and off, or managing ricing CFLAGS/debugging/features...
Controlling PYTHON_ABIS via eselect == rebuilding half of the world every eselect python version change. Do we really want it to behave that way?
But eselect should be user-switchable. Isn't it all just about "make selecting python ABI more clean&simple than by editing some creepy variables"? Use eselect for setting creepy variables and place them info *.conf.d directory - that's a common practice...
(In reply to comment #27) > But eselect should be user-switchable. Isn't it all just about "make > selecting python ABI more clean&simple than by editing some creepy > variables"? Use eselect for setting creepy variables and place them info > *.conf.d directory - that's a common practice... *Please open new bug* for this discussion. (and no - it's not that common)
(In reply to comment #24) > > > Let me repeat: what other USE_EXPAND variable has eselect module? > > > > Frankly, I don't care. As Zac said, I expect to set python versions to use > > trough eselect and then emerge to respect that. > > The problem lies in the above sentence: *you* expect, it doesn't mean that > everyone else does. And what exactly is wrong with expressing my opinion? I can talk only for myself and so I do. I'm not saying what everyone else expects, but apperantly I'm not the only one with that view on eselect. You think that you can talk for everyone?
(In reply to comment #29) > (In reply to comment #24) > > > > Let me repeat: what other USE_EXPAND variable has eselect module? > > > > > > Frankly, I don't care. As Zac said, I expect to set python versions to use > > > trough eselect and then emerge to respect that. > > > > The problem lies in the above sentence: *you* expect, it doesn't mean that > > everyone else does. > > And what exactly is wrong with expressing my opinion? There's nothing with expressing your opinion about eselect, but please do that in separate bug as this bug is about default value for PYTHON_TARGETS. > I can talk only for > myself and so I do. I'm not saying what everyone else expects, but > apperantly I'm not the only one with that view on eselect. You think that > you can talk for everyone? You're confusing eselect with variables that are in make.conf, as you've noticed also a few people think that those two are good as they are. And please don't put words in my mouth -- I've never said that I'm 'everyone'.
(In reply to comment #30) > as this bug is about default value for PYTHON_TARGETS. Maybe you should change summary for this bug then? Just to make _that_ clear (it's not)...
(In reply to comment #31) > (In reply to comment #30) > > as this bug is about default value for PYTHON_TARGETS. > > Maybe you should change summary for this bug then? Just to make _that_ clear > (it's not)... Done (if it's still not clear from overly long discussion).
okay so setting a default value for PYTHON_TARGETS is a good idea .. but the question arises .. how does it track the python versions installed? or does every python build now need to add itself to this variable when installed and remove itself when uninstalled .. at least I hope that is how it will work .. .. Saves the poor newbie from going crazy .. me .. I've been around for a while but the surprise of seeing the initial behaviour caused me to file this bug .. it would not be obvious to the non-initiates .. just baffling and potentially discouraging .. and inconsistent with previous behaviour ..
At this point, haven't we (as in Mike G.) already set python2_7 as a default PYTHON_TARGET? So is this discussion just about adding python3 in there, or adding all installed pythons? I agree with some of the commenters that we have a problem in the sense that eselect and PYTHON_TARGETS may not be in agreement, and this creates very weird scenarios. Even if eselect is just the tool to select the default python executable from among the installed pythons and PYTHON_TARGETS decides which pythons are installed by default and what versions of python python packages are installed for, we need to be very clear about communicating that to users (I got bitten by this myself yesterday, on a box where I'd forgotten I'd set USE_PYTHON).
(In reply to comment #34) > At this point, haven't we (as in Mike G.) already set python2_7 as a default > PYTHON_TARGET? So is this discussion just about adding python3 in there, or > adding all installed pythons? > I committed PYTHON_TARGETS="python2_7" to the base profile about 10 minutes ago. > I agree with some of the commenters that we have a problem in the sense that > eselect and PYTHON_TARGETS may not be in agreement, and this creates very > weird scenarios. Even if eselect is just the tool to select the default > python executable from among the installed pythons and PYTHON_TARGETS > decides which pythons are installed by default and what versions of python > python packages are installed for, we need to be very clear about > communicating that to users (I got bitten by this myself yesterday, on a box > where I'd forgotten I'd set USE_PYTHON). Perhaps we could just have eselect python suggest that the user should PYTHON_TARGETS themselves, and give them an example for copy/paste into make.conf. Would that be an ok compromise?
(In reply to comment #35) > I committed PYTHON_TARGETS="python2_7" to the base profile about 10 minutes > ago. Now fresh system just after installation from stage3 has Python 3.2 and PYTHON_TARGETS="python2_7". Very logical, very consistent. I'd say that new eclass discussion (which is *really* called for) should be moved from bugzilla to gentoo-python ML or (even better) to Gentoo forums and kept in one place.
Yeah, moving this discussion to a mailing list is probably a good idea.
(In reply to comment #36) > (In reply to comment #35) > > I committed PYTHON_TARGETS="python2_7" to the base profile about 10 minutes > > ago. > > Now fresh system just after installation from stage3 has Python 3.2 and > PYTHON_TARGETS="python2_7". Very logical, very consistent. You're aware that you can set it to anything you want, including PYTHON_TARGETS="python2_7 python3_2 python1018478_14873284", right? > I'd say that new eclass discussion (which is *really* called for) should be > moved from bugzilla to gentoo-python ML or (even better) to Gentoo forums > and kept in one place. "eclass discussion" happened a long time ago, now we're discussing default value for PYTHON_TARGETS. @Mike: I had the impression you would commit PYTHON_TARGETS="python2_7 python3_2", can we update it to include latest py2 and py3? I also like the solution for eselect to *suggest* PYTHON_TARGETS value, not set it (maybe even with a check if suggested value differs from current).
(In reply to comment #38) > @Mike: I had the impression you would commit PYTHON_TARGETS="python2_7 > python3_2", can we update it to include latest py2 and py3? this. please.
(In reply to comment #38) > @Mike: I had the impression you would commit PYTHON_TARGETS="python2_7 > python3_2", can we update it to include latest py2 and py3? Will do. I need to do this in arch-specific profiles because python:3.2 is not keyword-ed the same on all arches.
(In reply to comment #38) > You're aware that you can set it to anything you want, including > PYTHON_TARGETS="python2_7 python3_2 python1018478_14873284", right? Indeed I am. But I still think that providing system with default configuration that *doesn't make sense whatsoever* is a bit strange. > "eclass discussion" happened a long time ago Is it polite way of saying "please shut up, you're too late, new eclass has been set in stone, take it or leave..." oh wait, I can't leave it unless I leave Gentoo as well. If so, I'll be silent. Or is Python herd still inclined to listen to user's feedback?
(In reply to comment #40) > Will do. I need to do this in arch-specific profiles because python:3.2 > is not keyword-ed the same on all arches. Got it :) Thank you Mike. (In reply to comment #41) > (In reply to comment #38) > > You're aware that you can set it to anything you want, including > > PYTHON_TARGETS="python2_7 python3_2 python1018478_14873284", right? > Indeed I am. But I still think that providing system with default > configuration that *doesn't make sense whatsoever* is a bit strange. > > > "eclass discussion" happened a long time ago > Is it polite way of saying "please shut up, you're too late, new eclass has > been set in stone, take it or leave..." oh wait, I can't leave it unless I > leave Gentoo as well. If so, I'll be silent. Or is Python herd still > inclined to listen to user's feedback? That was a nice way to say to stop beating a dead horse. Calm down.
I have added PYTHON_TARGETS="python3_2" to make.defaults for amd64, hppa, ppc, ppc64 and x86.
(In reply to comment #43) > I have added PYTHON_TARGETS="python3_2" to make.defaults for amd64, hppa, > ppc, ppc64 and x86. I have removed it for HPPA again and I have gone ~hppa on all affected 3.1/3.2 ebuilds. I don't agree that messing in profiles is the right solution for an eclass issue.
(In reply to comment #44) > (In reply to comment #43) > > I have added PYTHON_TARGETS="python3_2" to make.defaults for amd64, hppa, > > ppc, ppc64 and x86. > > I have removed it for HPPA again and I have gone ~hppa on all affected > 3.1/3.2 ebuilds. I don't agree that messing in profiles is the right > solution for an eclass issue. PYTHON_TARGETS is arch-dependent to some degree (it shouldn't specify unstable Python for given arch for example), so if you removed it from hppa and dropped to ~hppa for 3.x it should be fine.
Mike has added the defaults, closing this bug.
(In reply to comment #38) > I also like the solution for eselect to *suggest* PYTHON_TARGETS value, not > set it (maybe even with a check if suggested value differs from current). I have filed bug 416145 for an enhancement to eselect-python.
