| Summary: | dev-lang/ruby-1.9.1: parallel install fix | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Daniel Robbins <drobbins> |
| Component: | [OLD] Development | Assignee: | Gentoo Ruby Team <ruby> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | bugs_gentoo_org.Tim_OKelly |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
parallel make build fix 2 for ruby 1.9.1
Proposed _solving_ patch Correct patch this time |
||
|
Description
Daniel Robbins
2009-07-31 20:30:26 UTC
Created attachment 199758 [details, diff]
parallel make build fix 2 for ruby 1.9.1
Depending on a directories is a _bad_ idea, since that adds a dependency on the timestamp of the directory which is not the same as depending on the presence of the directory. And that seems to be a parallel INSTALL fix rather than a parallel BUILD fix. If you have a better fix that fixes this failure, post here, I'll use it instead. Post a damn failure log and I can try to reproduce and fix it. Take a look at the link I posted, and click "previous by thread" a couple of times and you'll have the relevant "damn" failure. And another thing, why does the Gentoo project allow you to get away with being so obnoxious on bugs.gentoo.org? No one should get treated this way by a representative of the Gentoo project. I am not obligated to send fixes upstream to Gentoo. The downside of this is that Gentoo users will not benefit from these fixes. I think that would be unfortunate. I also think that rude behavior sends a bad message to everyone about the maturity level and level of professionalism of the Gentoo project. Because you _boasted_ of having a _build_ fix for Ruby the other night, and it annoyed me to have to see a _broken_ parallel _install_ fix instead. And since you're not my employer (thank karma), nor you're a normal user who has just submitted a patch, but rather somebody that is expected (and boasts of) knowing better, my professionalism is still in stand-by. If the bug fix does not meet your expectations, this does not give you the justification to be verbally abusive in a bug report. I am trying to be helpful. Let me just repeat what I have said before in case you did not hear me, or interpreted it in a negative light - I appreciate the work you do for Gentoo, and I support your efforts to improve QA. If you have a better fix for the issue at hand, I would gladly commit it to the Funtoo Portage tree and I would be appreciative of your effort. I hope you are appreciative that you are at least now aware of the parallel make failure, even if you do not find the fix I posted to meet your personal standards. I wasn't "boasting" about this fix to you earlier, I was using it as a peace offering in your earlier rant against Funtoo in which you made a number of negative comments about QA and Gentoo/Funtoo collaboration. The fact is, I want to try to work with you -- are you interested in bug reports? Or do you just want to be able to rant about Funtoo and how uncooperative we are? If you don't want me to send bug reports upstream to Gentoo, that's fine, but then could I ask that you stop complaining that Funtoo is not trying to collaborate with you? Collaboration is a two-way street -- it requires your sincere and respectful participation. I think I'm speaking for the whole Ruby team when I say that we're glad to collaborate, if it's an equal collaboration. This mean that rather than receiving reports for "this was broken, here's my patch that works-for-me", we'd like to have a report of "here's a problem, and this patch works"; if you don't have the patch, that's just as fine. I can understand that nobody can know about anything and especially corner cases; and I do appreciate to know how that the mkmf is broken _and_ we're also using a broken patch. I'll be working on it tomorrow, since tonight I'm still swamped with the paid job. For what concerns the problem of this patch, as well as the one in portage, the problem is that it addresses a somewhat Portage-specific problem and replaces it with another. The original problem is that the code wasn't written keeping in mind the use of staging trees were /usr/bin and other directories are not present beforehand. Depending on a directory will cause it to depend on the directory's mtime and not on the presence of it: flame@yamato foo % mkdir foo flame@yamato foo % stat -c '%Y' foo 1249082013 flame@yamato foo % touch foo/bar flame@yamato foo % stat -c '%Y' foo 1249082018 this _may_ produce infinite loops or parallel breakage inside the staging tree used by Portage (and almost any other package manage on this world), although that's particularly rare (likely happens only on filesystems that have sub-second timestamps like xfs and tmpfs). But it _will_ cause the "make install" of manually-installed ruby packages to copy back the files even if they weren't updated, if anything is touched inside /usr/bin. Regarding two off-topic points now (that will be my last writing here addressing those since this is a bug for a problem): a) I don't retract what I said about funtoo's QA; it wasn't meant as an insult, but you seem to have taken it like so, still I maintain that you _are_ trading off QA for basic user experience (“it builds“); that's your call, my note ( http://identi.ca/conversation/7220699#notice-7221045 ) was just one of preference; b) given sometimes having a bit of history/context/cornercase details can save you work and us the frustration of getting back data/results/patches we know already of, don't care for or similar, you really should try to _contact_ people first; my contact details are quite public ( http://www.flameeyes.eu/contact ) if you wish to contact me, or you may want to contact anybody else. Created attachment 203061 [details, diff]
Proposed _solving_ patch
Sorry for the delay but bills need to be paid as well. This patch (untested!) should solve the issue once and for all. I'll be home in the weekend without a job taking my time and I should be able to test it.
I'm not sure though if it's upstream-worth, what they tried to do was to actually create the directories just once, but they failed at make knowledge in the first place. I could write a deeper patch that solved the issue, but I'm not sure if they are really interested in that.
Created attachment 203585 [details, diff]
Correct patch this time
Whoopsie! I forgot the \n in the mkdir lines. This time it works, tested!
In _p243. Thanks. |
