USE flags python and perl enable language bindings for various packages, and those are useful only for very narrow group of people. As a unpleasant side effect, they usually cause heavy dependencies, like python bindings for Qt/KDE/Gtk/Gnome, and first two are known troublemakers, especially when dealing with Qt4 split ebuilds (as PyQT is usually very closely matched with Qt in terms of dependencies) and PyKDE4 which is known to fail compiling on some configurations. I always disabled those two and I don't remember any need to enable those bindings to make my system function properly, so they are perfect candidates to be dropped (disabled by default) from profile in my opinion, as they used to cause problems for many users being unaware of them.
Interesting suggestion. Assigning to release team for consideration. If they don't know any significant reasons why this change should not be made, this topic should probably be brought up on the gentoo-dev mailing list.
Are the 'python' and 'perl' USE *only* used to control the building of additional bindings? Are there any packages (especially system ones) where disabling these USE flags would be detrimental? A yes here isn't a show stopper. We can always use IUSE defaults to enable them by default on a per-package basis. Feel free to bring it up on -dev. I don't know of any reason this can't be done off the top of my head.
I've been using USE="-perl -python" in my make.conf for quite some time here without hitting any problems, only two exceptions in package.use which are net-irc/irssi perl (only adds a dependency on dev-lang/perl, irssi scripts are written in perl, candidate for IUSE defaults imho) and dev-libs/libxml2 python (only adds a dependency on dev-lang/python, some package wanted it). So I guess it's fine to remove those from the profiles
Created attachment 175615 [details] ebuilds built_with_use <something> (perl|python) Attached is a list of ebuilds which do a built_with_use check for USE=perl/python on some package. These are likely candidates for EAPI=2 use-deps (subject to portage 2.1.6.1 going stable) $ grep -rHe "built_with_use.*\(python\|perl\)" /usr/portage/ > perl_python_use_deps.list
Created attachment 231599 [details] Updated list
I have some feedback to add to this bug, to (hopefully) get it moving. 1) Know that I have personally ran desktop(s) AND server(s) with global 'USE="-python -perl"' with no ill effects. The few packages that complained, already had IUSE defaults (some xfce applet and git/svn). This is purely anecdotal evidence since other people will have other packages installed that I don't 2) I just unpacked a fresh stage3 (stage3-i686-20110809.tar), toggled python/perl flags, emerge -e world. There were no dependency issues or compiliation issues found. So, as far as it concerns releng@, there will be no known stage3 failures AFAICS.
Created attachment 283933 [details] build_with_use {perl,python} Thanks Jeremy! Meanwhile on build_with_use front...
(In reply to comment #7) > Created attachment 283933 [details] > build_with_use {perl,python} > > Thanks Jeremy! > > Meanwhile on build_with_use front... Maciej, there are *some* false hits in your list. Anyway, current status: > /usr/portage/dev-vcs/git/git-9999.ebuild: if use subversion && has_version dev-vcs/subversion && ! built_with_use --missing false dev-vcs/subversion perl ; then > /usr/portage/dev-vcs/git/git-1.7.3.5-r2.ebuild: if use subversion && has_version dev-vcs/subversion && ! built_with_use --missing false dev-vcs/subversion perl ; then > /usr/portage/dev-vcs/git/git-1.7.4.ebuild: if use subversion && has_version dev-vcs/subversion && ! built_with_use --missing false dev-vcs/subversion perl ; then > /usr/portage/dev-vcs/git/git-1.7.5_rc1.ebuild: if use subversion && has_version dev-vcs/subversion && ! built_with_use --missing false dev-vcs/subversion perl ; then > /usr/portage/dev-vcs/git/git-1.7.4.4.ebuild: if use subversion && has_version dev-vcs/subversion && ! built_with_use --missing false dev-vcs/subversion perl ; then > /usr/portage/dev-vcs/git/git-1.7.6.ebuild: if use subversion && has_version dev-vcs/subversion && ! built_with_use --missing false dev-vcs/subversion perl ; then > /usr/portage/dev-vcs/git/git-1.7.2.5.ebuild: if use subversion && has_version dev-vcs/subversion && ! built_with_use --missing false dev-vcs/subversion perl ; then > /usr/portage/dev-vcs/git/git-1.7.5_rc3.ebuild: if use subversion && has_version dev-vcs/subversion && ! built_with_use --missing false dev-vcs/subversion perl ; then > /usr/portage/dev-vcs/git/git-1.7.4.1.ebuild: if use subversion && has_version dev-vcs/subversion && ! built_with_use --missing false dev-vcs/subversion perl ; then > /usr/portage/dev-vcs/git/git-1.7.3.5-r1.ebuild: if use subversion && has_version dev-vcs/subversion && ! built_with_use --missing false dev-vcs/subversion perl ; then > /usr/portage/dev-vcs/git/git-1.7.3.5.ebuild: if use subversion && has_version dev-vcs/subversion && ! built_with_use --missing false dev-vcs/subversion perl ; then > /usr/portage/dev-vcs/git/git-1.7.3.4-r1.ebuild: if use subversion && has_version dev-vcs/subversion && ! built_with_use --missing false dev-vcs/subversion perl ; then > /usr/portage/dev-vcs/git/git-1.6.4.5.ebuild: if use subversion && has_version dev-vcs/subversion && ! built_with_use --missing false dev-vcs/subversion perl ; then > /usr/portage/dev-vcs/git/git-1.7.4.5.ebuild: if use subversion && has_version dev-vcs/subversion && ! built_with_use --missing false dev-vcs/subversion perl ; then > /usr/portage/dev-vcs/git/git-1.7.5.3.ebuild: if use subversion && has_version dev-vcs/subversion && ! built_with_use --missing false dev-vcs/subversion perl ; then All but one (old, supersceded) git ebuilds fixed: + 19 Aug 2011; Jeremy Olexa <darkside@gentoo.org> git-1.7.2.5.ebuild, + git-1.7.3.4-r1.ebuild, git-1.7.3.5.ebuild, git-1.7.3.5-r1.ebuild, + git-1.7.3.5-r2.ebuild, git-1.7.4.ebuild, git-1.7.4.1.ebuild, + git-1.7.4.4.ebuild, git-1.7.4.5.ebuild, git-1.7.5_rc1.ebuild, + git-1.7.5_rc3.ebuild, git-1.7.5.3.ebuild, git-1.7.6.ebuild, git-9999.ebuild: + Remove useless/redundant built_with_use check for subversion[perl] since the + addition of USE-deps. Signed off by maintainer. Tangentially related to bug + 250179 > /usr/portage/eclass/vim.eclass: elif ! built_with_use =dev-lang/python-2* threads; then false hit > /usr/portage/net-irc/epic4/ChangeLog: Added some built_with_use magic to make sure perl has been compiled with false hit > /usr/portage/net-nds/openldap/openldap-2.3.43-r1.ebuild: if has_version "<=dev-lang/perl-5.8.8_rc1" && built_with_use dev-lang/perl minimal ; then false hit > /usr/portage/rox-extra/musicbox/musicbox-027-r2.ebuild:# if ! built_with_use dev-lang/swig python; then real hit, but commented out. > /usr/portage/sys-apps/paludis/paludis-0.64.0.ebuild: ! built_with_use --missing true dev-libs/boost python; then > /usr/portage/sys-apps/paludis/paludis-0.64.2.ebuild: ! built_with_use --missing true dev-libs/boost python; then > /usr/portage/sys-apps/paludis/paludis-0.58.5.ebuild: ! built_with_use --missing true dev-libs/boost python; then > /usr/portage/sys-apps/paludis/paludis-0.60.4.ebuild: ! built_with_use --missing true dev-libs/boost python; then > /usr/portage/sys-apps/paludis/paludis-0.64.1.ebuild: ! built_with_use --missing true dev-libs/boost python; then > /usr/portage/sys-apps/paludis/paludis-0.62.2.ebuild: ! built_with_use --missing true dev-libs/boost python; then paludis maintainer should do something about this, I don't think it matters in the grand scheme (personal opinion) > /usr/portage/app-emulation/crossover-office-pro-bin/crossover-office-pro-bin-4.2.ebuild: ! built_with_use dev-lang/perl ithreads \ false hit > /usr/portage/app-emulation/virtualbox/virtualbox-9999.ebuild: if use python && ! built_with_use dev-lang/python threads ; then false hit > /usr/portage/sci-chemistry/vmd/ChangeLog: Remove built_with_use and use proper DEPEND atoms that work properly for false hit > /usr/portage/net-mail/mailgraph/mailgraph-1.14.ebuild: built_with_use net-analyzer/rrdtool perl \ bug 379893 > /usr/portage/net-misc/asterisk/ChangeLog: Added additional built_with_use checks for perl and libperl, because res_perl false hit > /usr/portage/dev-util/imediff2/imediff2-1.1.2-r1.ebuild: if ! built_with_use --missing true dev-lang/python ncurses ; then false hit > /usr/portage/media-sound/picard/ChangeLog: Add a built_with_use check foru python and cxx use flag, bug #230225 > /usr/portage/media-video/totem/ChangeLog: Add built_with_use check for threading in python in the use=python case false hits > /usr/portage/media-video/tovid/tovid-0.31-r2.ebuild: if use tk && ( ! built_with_use dev-lang/python tk ); then false hit > /usr/portage/net-analyzer/aimsniff/aimsniff-0.9-r1.ebuild: built_with_use dev-lang/perl gdbm || \ false hit.
Ohh don't be so picky, everyone sees that looking at attached file :)
(In reply to comment #9) > Ohh don't be so picky, everyone sees that looking at attached file :) Ok :) Just sayin' that your list is pretty small. I'd even say small enough to go forward with this endeavour.
In case anyone is willing / wishing to test stages built with the perl and python use flags dropped from default/linux profile, I've uploaded amd64 stages (20110822) to my server[1]. I'll upload x86 stages when they're finished. [1] - http://www.jmbsvicetto.name/releases/
(In reply to comment #10) > (In reply to comment #9) > > Ohh don't be so picky, everyone sees that looking at attached file :) > > Ok :) Just sayin' that your list is pretty small. I'd even say small enough to > go forward with this endeavour. Well, no one else is interested in moving forward so I'm going to announce the removal of python/perl from the profiles on -dev-announce. Speak up now, please.
Big thanks for getting this ball rolling.
+ 05 Oct 2011; Jeremy Olexa <darkside@gentoo.org> default/linux/make.defaults: + Remove USE={python,perl} from default profile, as discussed/announced. Bug + 250179
(In reply to comment #2) > Are the 'python' and 'perl' USE *only* used to control the building of > additional bindings? > > Are there any packages (especially system ones) where disabling these USE flags > would be detrimental? A yes here isn't a show stopper. We can always use IUSE > defaults to enable them by default on a per-package basis. > > Feel free to bring it up on -dev. I don't know of any reason this can't be done > off the top of my head. Compiling x11-terms/rxvt-unicode without "perl" USE flag make it lose the ability to use tabs to host severals terminals. Ok that's not a system component, but it's an essential feature of rxvt.
(In reply to comment #15) > (In reply to comment #2) > > Are the 'python' and 'perl' USE *only* used to control the building of > > additional bindings? > > > > Are there any packages (especially system ones) where disabling these USE flags > > would be detrimental? A yes here isn't a show stopper. We can always use IUSE > > defaults to enable them by default on a per-package basis. > > > > Feel free to bring it up on -dev. I don't know of any reason this can't be done > > off the top of my head. > > Compiling x11-terms/rxvt-unicode without "perl" USE flag make it lose the > ability to use tabs to host severals terminals. > Ok that's not a system component, but it's an essential feature of rxvt. Open a bug to the rxvt-unicode maintainers and ask them to add perl to IUSE defaults.
(In reply to comment #16) > (In reply to comment #15) > > (In reply to comment #2) > > > Are the 'python' and 'perl' USE *only* used to control the building of > > > additional bindings? > > > > > > Are there any packages (especially system ones) where disabling these USE flags > > > would be detrimental? A yes here isn't a show stopper. We can always use IUSE > > > defaults to enable them by default on a per-package basis. > > > > > > Feel free to bring it up on -dev. I don't know of any reason this can't be done > > > off the top of my head. > > > > Compiling x11-terms/rxvt-unicode without "perl" USE flag make it lose the > > ability to use tabs to host severals terminals. > > Ok that's not a system component, but it's an essential feature of rxvt. > > Open a bug to the rxvt-unicode maintainers and ask them to add perl to IUSE > defaults. Ok, thanks, for reference is bug #386827
