iojs has this in DEPEND (and not RDEPEND): =net-libs/http-parser-2.3 this causes http-parser to upgrade/downgrade constantly. packages should not be pinning to specific versions that aren't slotted.
The downgrade was intentional since that's what upstream also did. I guess we're going to have to introduce a slot for http-parser then?
Also, it should really be RDEPEND. My bad.
i don't think SLOT-ing makes sense here. i would one of: (1) make the package work with a newer version regardless of upstream (2) mask the package until upstream sorts their business out i'm not familiar with iojs and why they've pinned this version, but i have seen upstreams pin versions before purely because they didn't have resources to verify newer ones. in cases like that, it's perfectly fine to ignore the pinned dep and allow newer versions in the ebuild. of course, if iojs doesn't actually work with newer ones, that's a different story.
Thanks for your reply. I guess I should also mention that I'm probably going to be part of the io.js working group. I'm already part of their build team, which means I've been able to improve the package state not only for Gentoo but also for others. The package will work with a newer http-parser. It was just rolled back because of a nasty bug in http upgrade. I chose to follow upstream to avoid broken tests. The reason I've chosen to pin versions is because I wanted to follow upstream. If we for instance allow openssl 1.0.2, additional tests will break. In terms of other dependencies, we usually lag in terms of versions io.js bundles (but I try to be on top of it). The alternative available to us is linking io.js statically, which I'm not very keen on - or accepting that tests will fail. We already have a test fail I've sed'ed out that I've only been able to reproduce from within portage (doesn't seem related to sandbox though).
oh, this is the package that was attempting to force a downgrade in openssl on my system ? the problem is that by messing with the libraries like this, you could easily break other packages. consider: - user upgrades to openssl-1.0.2 which includes new symbols but has same SONAME as openssl-1.0.1 - user installs package which detects & uses those new symbols - user installs iojs which forces a downgrade - user's system is now silently broken now consider when that package is something like openssh. you've just broken remote login to the system. no, this is not theoretical ;). if the only consequence is failing tests, then you should live with that, and possibly add an ewarn to the src_test phase when they do fail. if the libs you depend upon have bugs, then you should hassle the maintainers of those libs to fix said bugs rather than forcing an older version.
(In reply to SpanKY from comment #5) > oh, this is the package that was attempting to force a downgrade in openssl > on my system ? the problem is that by messing with the libraries like this, > you could easily break other packages. Most likely. > > consider: > - user upgrades to openssl-1.0.2 which includes new symbols but has same > SONAME as openssl-1.0.1 > - user installs package which detects & uses those new symbols > - user installs iojs which forces a downgrade > - user's system is now silently broken > > now consider when that package is something like openssh. you've just > broken remote login to the system. no, this is not theoretical ;). I understand. My hope was that unstable vs stable would be a nice threshold for how much I could assume users would understand the issues with similar scenarios. > > if the only consequence is failing tests, then you should live with that, > and possibly add an ewarn to the src_test phase when they do fail. if the > libs you depend upon have bugs, then you should hassle the maintainers of > those libs to fix said bugs rather than forcing an older version. Well, tests reflect intended behaviour, right? :) I'm obviously not going to fight you on this -- most libraries are forward compatible and the one's that break should be slotted anyway. The downgrade of http-parser was unfortunate. I'll be more vigilant for similar issues reported in Gentoo, but it's somewhat annoying to get failed test suites thrown at you (which if I wasn't a developer would be sent upstream. They would in turn despise Gentoo for not using the bundled deps. You know how it goes..) I'll post an -r1 that lessens the deps as well as moves proper libs to RDEPEND. Thanks again for your useful feedback and helpful discussion.
(In reply to Johan Bergström from comment #6) certainly failing tests are a bad thing. but the right resolution depends on why the failures are occurring: the package using the library is bad, the library itself is bad, or interaction between the two isn't reasonably resolvable. if the library you depend on is broken, when it comes to the ebuild, you might consider something like: src_test() { if ! has_version '~net-libs/http-parser-2.3'; then ewarn "Tests are known to fail when using newer http-parser; see http://bugs.gentoo.org/1234" fi emake check # or whatever } or if the test harness has XFAIL (expected-to-fail) support, you could mark the specific failing tests as such.
(In reply to SpanKY from comment #7) > (In reply to Johan Bergström from comment #6) > > certainly failing tests are a bad thing. but the right resolution depends > on why the failures are occurring: the package using the library is bad, the > library itself is bad, or interaction between the two isn't reasonably > resolvable. if the library you depend on is broken, > > when it comes to the ebuild, you might consider something like: > src_test() { > if ! has_version '~net-libs/http-parser-2.3'; then > ewarn "Tests are known to fail when using newer http-parser; see > http://bugs.gentoo.org/1234" > fi > emake check # or whatever > } > > or if the test harness has XFAIL (expected-to-fail) support, you could mark > the specific failing tests as such. Would this be good enough as a first stab? As for covering test failures on different library combinations - I'd rather add them as they are reported. That way I can XFAIL upstream instead. Again, thanks for your input. --- /usr/portage/net-libs/iojs/iojs-1.5.1.ebuild 2015-03-10 14:20:07.000000000 +1100 +++ iojs-1.5.1.ebuild 2015-03-12 13:32:35.055457016 +1100 @@ -20,15 +20,13 @@ KEYWORDS="~amd64 ~arm ~x86 ~x64-macos" IUSE="icu +npm snapshot" -RDEPEND="!!net-libs/nodejs - >=dev-libs/openssl-1.0.1j[-bindist] - <dev-libs/openssl-1.0.2:=[-bindist]" -DEPEND="${PYTHON_DEPS} - ${RDEPEND} +RDEPEND=">=dev-libs/openssl-1.0.1j[-bindist] icu? ( dev-libs/icu ) - =net-libs/http-parser-2.3 + >=net-libs/http-parser-2.3 >=dev-libs/libuv-1.4.2" - +DEPEND="${RDEPEND} + ${PYTHON_DEPS} + !!net-libs/nodejs" S="${WORKDIR}/${MY_P}" pkg_pretend() { @@ -109,4 +107,4 @@ find "${LIBDIR}"/node_modules -type f -name "LICENSE" -delete pax-mark -m "${ED}"/usr/bin/iojs -}
the dep changes look fine ... assuming that last hunk to delete the } is a typo
