dev-python/django-1.0.2 shouldn't depend on subversion. Most administrators won't want to install subversion just to use a web framework. Reproducible: Always Steps to Reproduce: emerge -pv =dev-python/django-1.0.2 Actual Results: Calculating dependencies... done! [ebuild N ] dev-python/imaging-1.1.5 USE="-X -doc -scanner -tk" 420 kB [ebuild N ] net-misc/neon-0.28.3 USE="nls ssl zlib -doc -expat -gnutls -kerberos -pkcs11 -socks5" LINGUAS="-cs -de -fr -ja -nn -pl -ru -tr -zh_CN" 781 kB [ebuild N ] dev-util/subversion-1.5.4 USE="apache2 berkdb dso nls perl python webdav-neon -bash-completion -debug -doc -emacs -extras -java -ruby -sasl -vim-syntax -webdav-serf" 4,810 kB [ebuild N ] dev-python/django-1.0.2 USE="vhosts -bash-completion -doc -examples -mysql -postgres -sqlite3" 0 kB Expected Results: Calculating dependencies... done! [ebuild N ] dev-python/imaging-1.1.5 USE="-X -doc -scanner -tk" 420 kB [ebuild N ] dev-python/django-1.0.2 USE="vhosts -bash-completion -doc -examples -mysql -postgres -sqlite3" 0 kB The dependency results from the ebuild inheriting subversion. Subversion is only actually used if the "test" flag is enabled. The options would seem to be: 1. Remove the testing functionality 2. Have a DEPEND on subversion only with the "test" flag enabled, then re-implement the relevant parts of subversion_fetch in the ebuild.
Created attachment 182492 [details, diff] ebuild that removes testing functionality This patch drops the testing functionality from the ebuild, removing the subversion dependency
As django upstream has removed the tests from the tarballs we're forced to do such silly things. I'm unwilling to give up the test function, so it'll stay there (and subversion is only pulled in with FEATURES="test" anyway)
(In reply to comment #2) > As django upstream has removed the tests from the tarballs we're forced to do > such silly things. I'm unwilling to give up the test function, so it'll stay > there (and subversion is only pulled in with FEATURES="test" anyway) > Since subversion.eclass is inherited unconditionally (it needs to be so as to not invalidate metadata), subversion is always required. However, I wonder if this is a valid case for conditional inherits since inheriting subversion does not change any global-scope stuff at all (atleast we don't want any of those changes)
subversion.eclass should be patched to allow a custom depend on subversion, which should then only be pulled if tests are enabled. building the whole subversion bloat just for the sake of having a test function while having tests disabled is unacceptable.
Created attachment 189629 [details, diff] subversion.eclass patch
Created attachment 189632 [details, diff] django.ebuild patch
(In reply to comment #5) > Created an attachment (id=189629) [edit] > subversion.eclass patch Other variables in subversion.eclass have names starting with "ESVN_". What do you think about ESVN_DISABLE_AUTOMATIC_DEPENDENCIES or ESVN_OPTIONAL_DEPEND{,ENCIES} instead of SUBVERSION_OPTIONAL?
I fail to see the reason why a mirror://gentoo tarball can't be made of the missing parts from an SVN checkout. Either the tests pulled by SVN are static and a distfiles-local tarball is a valid way to distribute them, or they're being updated which would imply tests are not repeatable which would be worrying. It appears from their Trac[1] that no updates are being made, so requiring SVN irrespective of FEATURES=test seems quite pointless. [Thoughts from a user without access to machine where SVN can be installed] 1. http://code.djangoproject.com/browser/django/tags/releases/1.0.2
(In reply to comment #7) > (In reply to comment #5) > > Created an attachment (id=189629) [edit] > > subversion.eclass patch > > Other variables in subversion.eclass have names starting with "ESVN_". > What do you think about ESVN_DISABLE_AUTOMATIC_DEPENDENCIES or > ESVN_OPTIONAL_DEPEND{,ENCIES} instead of SUBVERSION_OPTIONAL? yes, that's ok with me too, as long as one can disable it somehow. feel free to fix the issue in django too (In reply to comment #8) > I fail to see the reason why a mirror://gentoo tarball can't be made > of the missing parts from an SVN checkout. this is a valid question, but i assume, the svn solution is the lazy maintainers approach to not have to upload a tarball with every release.
Fixed. I created django-1.0.2-tests.tar.bz2. subversion.eclass now also supports ESVN_DISABLE_DEPENDENCIES variable.
