I have a problem with this bit of logic from the openrc-9999.ebuild: if [[ ${PV} == "9999" ]] ; then ESVN_REPO_URI="svn://" inherit subversion else SRC_URI="http://roy.marples.name/downloads/${PN}/${P}.tar.bz2 mirror://gentoo/${P}.tar.bz2 http://dev.gentoo.org/~cardoe/files/${P}.tar.bz2 http://dev.gentoo.org/~vapier/dist/${P}.tar.bz2" fi Obviously, the -9999 version is meant to be a sort of wildcard which pulls the latest from trunk. This works great for me at home, because I have enabled svn access to external sites. However, my work systems live on a vast network where the border is not owned by me. :D And SVN traffic is blocked. Of course, this ebuild fails with: "svn: Can't connect to host 'roy.marples.name': Connection refused " So, I have to mask the -9999 version of the package in order for baselayout to install it. There are a couple ways to fix this I guess: * enable http proxy for the svn traffic at roy.marples.name (and then update the ebuild to use http:// rather than svn://) * have the owner of openrc publish a 'nightly' tar.bz2 which this ebuild pulls and installs * don't use a wildcard like this by default. Do we really want the 'default' behaviour to be "install what's in trunk - sure it should be tested"?? In this case, perhaps it's the baselayout-2.0.0 ebuild which should be more specific than: PDEPEND="sys-apps/openrc" Now that I've gone through all these options, I think the third option is probably the most sensible. Just make baselayout-2.0.0 depend on a specific version of openrc. I am happy to go and make this change actually, if you guys agree it's the right thing. Please have a look and let me know what you think. Thanks! -- Matt Reproducible: Always Steps to Reproduce: 1. Block SVN traffic to the public internet 2. attempt to emerge baselayout Actual Results: "svn: Can't connect to host 'roy.marples.name': Connection refused Expected Results: Installed baselayout and all dependencies, including openrc. I'm open to be wrong here, but I think that baselayout should declare a specific version of the openrc software it depends on, which will cause the openrc ebuild to use the http to pull a tar.bz2 of the software, which will be supported on most networks, and at least can be subject to the site's http_proxy environment variable.
This bug report really makes no sense. You choose to unmask the -9999 version and as such, you should be able to fix it yourself. If you cannot do this then don't use the live ebuild.
By the way, options 1 and 2 are out of Gentoo's control. Option 3 is normal operating procedure, -9999 doesn't have any keywords so the end user has to manually add an entry to /etc/portage/*. Nothing is automatic/default about using the live ebuild. As such, resolving this bug as invalid. You can try to convince me otherwise, but it will take some seriously good points other than what you listed. Thanks.
