Hi In order to emerge sys-libs/glibc-2.14.1-r2 patch-2.6+ is necessary. The problem is that sys-libs/glibc-2.14.1-r2 ebuild does not impose build dependency on sys-devel/patch. Tested on paludis only. See my first post here: http://lists.pioto.org/pipermail/paludis-user/2012-January/001739.html Paludis devs comments was: http://lists.pioto.org/pipermail/paludis-user/2012-January/001742.html Reproducible: Always
cvs/gentoo-x86/sys-libs/glibc $ ebuildvar DEPEND|grep patch glibc-2.13-r2.ebuild : !<sys-devel/patch-2.6 glibc-2.13-r4.ebuild : !<sys-devel/patch-2.6 glibc-2.14.ebuild : !<sys-devel/patch-2.6 glibc-2.14.1.ebuild : !<sys-devel/patch-2.6 glibc-2.14.1-r1.ebuild : !<sys-devel/patch-2.6 glibc-2.14.1-r2.ebuild : !<sys-devel/patch-2.6 glibc-2.15.ebuild : !<sys-devel/patch-2.6 Oh yes it does. It looks like paludis needs fixing. I think the norm is to not bother sys-apps/paludis' maintainer of the package in the tree, but to report upstream. CC'ing anyway to verify that.
! blocks do not impose order constraints. Only !! blocks do. Paludis is correct.
Not sure that it matters, but glibc does not define EAPI, and per PMS v4 table 9.4 the strength of blockers is undefined in EAPI0, and !! is forbidden. Just my reading of the spec though...
Yup, which means you can't assume either behaviour. If you specifically need an order-imposing blocker, you'll have to use an EAPI that supports it.
LOL
Cc:ing devrel: please remind Jer that bug changes like the one he just made (https://bugs.gentoo.org/show_activity.cgi?id=399407) are utterly inappropriate behaviour.
Devrel should be called after every other alternative have failed. Try to discuss it in private or contact the toolchain@ team if you think it is appropriate. If you still can't work things out, consult the devrel's policy[1] on how to proceed. [1]: http://www.gentoo.org/proj/en/devrel/policy.xml.
(In reply to comment #6) > Cc:ing devrel: please remind Jer that bug changes like the one he just made > (https://bugs.gentoo.org/show_activity.cgi?id=399407) are utterly inappropriate > behaviour. Ciaran, can you please list what change in particular you're complaining about? Also, to be precise, any complaint here should be sent to userrel and not devrel. At least I couldn't see any issues between developers on this bug.
I'm complaining about him maliciously changing the bug title from "sys-libs/glibc-2.14.1-r2 does not impose sys-devel/patch dependency" (which is accurate) to "sys-apps/paludis does not understand !<$CATEGORY/$P" (which is nonsense), and closing the bug as UPSTREAM, after it was explained in the bug why it's a dependency problem, not a Paludis problem.
Seems to me that either the dependency needs to be handled in some other way, or PMS needs to be changed, or glibc needs to use EAPI2. Any of those are Gentoo bugs. The simplest solution might be to change it from a blocker to a dependency - >=sys-devel/patch-2.6. The only issue there is if patch is provided by some other package on some arch I'm not thinking about - it is a system package. If anything that makes more sense to me - the problem isn't the presence of old versions of patch, but the non-presence of new versions of patch (not that I can imagine anybody ever slotting patch).
I would argue not a paludis bug. Vapier is sitting next to me though. I'll bug him about it.
the patch dep is a mitigation strategy. adding ">=patch-2.6" isn't acceptable because then glibc depends on patch. if you hit the unpack error, then `emerge -u patch` and get on with your work.
Not to re-open the recent -dev thread, but what is wrong with depending on patch? Per the devmanual requiring a specific version of a system package is a legitimate time to add one as a dependency. If that causes some even worse breakage I can understand just telling users to deal with the occasional bug since we don't want to change the EAPI on glibc.
@SpanKY Well. Of course I did manual update of patch. And it works. Not sure why I need to do it manually though.
because life isn't nice. for now, this is the status quo.
So, setting aside whether life is fair/nice/etc, is there a reason that it isn't appropriate to add a dependency on patch, rather than a blocker? It isn't clear to me why this isn't a valid solution to this issue.
strictly speaking, glibc doesn't require GNU patch-2.6+. it is only known to not work with GNU <patch-2.6. hence the dep reflects what is in play. how random PM's choose to interpret that expression, i don't care. realistically speaking, not many people utilize an alternative patch.
Your dependency says "patch <2.6 must not be installed by the time the resolution is finished". You need to use a !! blocker if you mean "patch <2.6 must not be installed before my install can start".
if it's not in EAPI=0, i'm not interested
Neither syntax is really in EAPI0 as far as this is concerned - I think that is the issue here. In any case, I think there is a legitimate bug here. Maybe it is changing the glibc ebuild, or perhaps it is changing PMS. The fact that there is a workaround doesn't make this super-critical. I don't think it is invalid though.
You have regular >= dependencies in EAPI 0. You can use those instead. After all, patch is already installed.
(In reply to comment #20) i never said/marked this as invalid :). it's WORKSFORME since it works fine for most people pretty sure blockers have existed longer than PMS, so yes, "!cat/pkg" is in EAPI=0. i can easily find references from 2003 using blockers. (In reply to comment #21) this conveniently ignores what was already said in comment #17
(In reply to comment #22) > pretty sure blockers have existed longer than PMS, so yes, "!cat/pkg" is in > EAPI=0. i can easily find references from 2003 using blockers. What is in EAPI 0 is defined in PMS. What's the point of having a spec if we're just going to ignore it? If the spec is wrong, it should be changed - not ignored. > this conveniently ignores what was already said in comment #17 Does it call patch? If so, then it is a dependency (even if it is agnostic about what patch it calls). If it doesn't, then how does having a particular version of it cause problems? Is there actually a real-world problem with capturing this as a patch dependency and not as a blocker? It seems like we're arguing purely for the sake of principles, and in that case I'd argue that a written PMS spec stating that a particular syntax is undefined outweighs, well, I'm not quite sure what the counter-argument being made is. Perhaps it is a vague reference to not having dependencies on system packages, but the only place that is written down explicitly calls out issues with particular versions of system packages as a case where they should be used. If adding a patch dependency causes a real-world problem then I'm fine with taking a pragmatic approach instead. Otherwise, it strikes me that this ebuild violates the specs. If software works contrary to its specifications that would seem to be the textbook definition of a bug.
The definition of ! in PMS for EAPI 0 says what it says because the Council decided that the spec should be retroactively updated to allow for a change that was made in Portage behaviour. Blockers changed behaviour in Portage shortly before !! blockers were introduced as a fix. You're only not seeing this with Portage too because of a coincidence in resolution orders.
(In reply to comment #23) > Does it call patch? If so, then it is a dependency (even if it is agnostic > about what patch it calls). If it doesn't, then how does having a particular > version of it cause problems? Lets se if we can make this clear once and for all: glibc DOES NOT NEED patch, or ever call it. glibc NEEDS THE PM to apply patches NOT using a too old version of sys-devel/patch. this means if a user uses a PM that for instance uses something else to apply the patches, or even has internal code to apply patches, then that users system does not need sys-devel/patch at all, so why should glibc pull it in? > Is there actually a real-world problem with capturing this as a patch > dependency and not as a blocker? This kind of thinking has actually resulted in bugs looking a lot like this. I will remember a bug a while pack that also became highly political and lots of unecessary angst because a dependecy glibc had on portage for similar reasons, something that did not go well toghether with the "I only want that other package manager"-camps. > If adding a patch dependency causes a real-world problem then I'm fine with > taking a pragmatic approach instead. Otherwise, it strikes me that this ebuild > violates the specs. If software works contrary to its specifications that > would seem to be the textbook definition of a bug. It may not create problems today, but this is one of those classics that tends to come back and make people bite each other for purely political reasons, creating all sorts of bad blood and dev-retirements.
Wait. Something other than epatch from eutils is applying patches here?
(In reply to comment #26) > Wait. Something other than epatch from eutils is applying patches here? Nope. However eclasses can be overriden by repos.conf, and what if someone somewhere thought it was a good idea to recreate epatch with python-patch [1], and then he was able to get enought people to think this is one of those famous "A Good Idea"? What happends when that userbase start to ask themselves "why does glibc depend on sys-devel/patch"? [1] http://code.google.com/p/python-patch/
(In reply to comment #26) > Wait. Something other than epatch from eutils is applying patches here? Or someone was able to show the benefits in having portage/paludis apply the patches insteada of having a eclass do it, and it is decided that should be the default for EAPI="Awesome"?
If someone does that, then they need to change EAPI. The EAPI used by glibc knows nothing about patches, so patching is just a normal program run by the ebuild. Package managers can't replace things in eclasses, since eclasses are allowed to introduce new functionality whenever they want.
(In reply to comment #23) the way i'm using blockers here has existed long before PMS and the whole concept of EAPI. seems to still work for the majority of users and not prevent all the other random users to adjust as need be. your logic about running commands falls once again into the same category as discussed on gentoo-dev. glibc runs a ton of packages not listed in DEPEND because they're part of system (i can count easily ~10 pkgs). to extend your point further, we're arguing over an issue that affects an insignificant number of users and at this point, i'd just as soon drop the patch dep completely and be done. the point, as i said, was merely to mitigate the situation for most people.
(In reply to comment #30) > the way i'm using blockers here has existed long before PMS and the whole > concept of EAPI. seems to still work for the majority of users and not prevent > all the other random users to adjust as need be. What you're doing *used* to work. However, Zac changed Portage's behaviour around the time when EAPI 2 came out, and the Council decreed that the change to Portage's behaviour should be reflected in PMS, so now ! blocks don't mean what they did originally. If you want the old behaviour, you have to use !! blocks in a newer EAPI.
(In reply to comment #31) fair point. however, given the dearth of bug reports on the issue indicating no one is really hitting this and the mitigation is doing a good job mitigating, and my desire to keep glibc at EAPI=0, i'm not inclined to make this perfect.
