https://bugzilla.redhat.com/show_bug.cgi?id=1097426
I've tried to get the packager of dpdk to play by the packaging guidelines wrt compiler flags. I do this a lot for a lot of packages, and almost without exception, maintainers respond favourably when the issues are pointed out to them.
But now for the dpdk case the only conclusion I can draw from the feedback is that the maintainer doesn't seem to care, nor (want to?) understand that if he chooses to override (or in this case, not use at all) RPM_OPT/LD_FLAGS, it is not me he needs to explain the reasoning why nor that it is not me who should educate myself why this package should be done someway different, but it is his responsibility to document the rationale for this stuff for everyone in the specfile. He's also failed to address some specific questions regarding questionable compiler flags being used (for example -march=core2 on i686) or why some flags from RPM_OPT_FLAGS would "conflict" (as he puts it in the specfile at the moment) with the package's upstream flags, and instead told me to go learn myself why the current state of affairs would be an appropriate thing to do for this package.
I've spent the time I have available for this, and based on the FESCo mission description in the wiki, I gather this is the correct place to escalate the issue to. If not, please point me out to an appropriate direction, thanks.
Perhaps if Ville would adjust his attitude we could communicate more easily, however, his agressive tone makes it almost impossible to speak with him. As it stands however, I'm working on correcting the issues that he point out, it just can't be done overnight, and as the packager with a relationship to the upstream community, I'm not overly concerned about the security risks imposed by not building with RPM_OPT_FLAGS at the moment, as the fedora package is meant for evaluation, and no one can be expected to build an application on it without also rebuilding the dpdk component.
Lets try and avoid talking about each others attitudes and work to make things better.
What happens if you just use the default flags? Is there an upstream bug or discussion about what breaks?
Fedora users don't have any way to know that the package is 'for evaluation'. Perhaps if it's not ready to be included, it should wait to enter the collection until those issues are sorted out?
Is the timeframe for fixing likely before f21 is released?
Replying to [comment:3 kevin]:
Now that we have Coprs, that's probably the best place for things which are in that state. But probably too late to drop this from the distro proper?
Thats the hope, to be fixed in the next few weeks
Please fix the package guideline violation.
FESCo will revisit the ticket on Aug 13th (+7, -0, 0:0)
I'm on vacation this week, I'm trying to get to it next week.
John Linville and I discussed some changes to the package, which he was kind enough to implement and push this morning. This should be fixed now.
The package still builds with -march=core2 and various SSE/SSE2/SSE3/SSSE3 defines which may not be what the latest changes tried to implement. But if these are issues in the first place, they're just ordinary packaging bugs which should be addressed by maintainers. Anyway the intent looks good now, so I don't think there's need for FESCo involvement any longer.
Thanks for letting us know, closing.
Login to comment on this ticket.