Proposal Topic
Allow Csmith, a tool that can generate random C programs to include header files.
Overview
Csmith is a tool that can generate random C programs that statically and dynamically conform to the C99 standard. It is useful for stress-testing compilers, static analyzers, and other tools that process C code.
Problem Space
csmith runtime includes customized header files (stdint_ia32.h, stdint_avr.h, stdint_msp430.h, custom_limits.h, stdint_ia64.h).
Upstream's reply on the usage of these header files:
"For the sake of everyone's sanity, I'd suggest that the Fedora-filed source package contain exactly what is in the output of `make dist'. I'd rather not be in the situation of having the Fedora package be greatly different than what we distribute, which leads to questions about which distributions people are using when they report bugs, etc. We already have enough problems with that, asking people to specify git commit hashes."
Solution Overview
Since, we would like to be as close to upstream, I hereby request an exception to include headers in the package.
Active ingredients
Package review request: https://bugzilla.redhat.com/show_bug.cgi?id=756321
Owners
Shakthi Kannan FAS: shakthimaan / IRC: mbuf
Reading what's here and what's in the review request, there doesn't seem to be a justification for an exception here. The bug seems to say that on Linux, the application will work fine with the system provided headers and it's just to make debugging easier that unbundling is being disputed by upstream.
BTW, staying close to upstream is not a reason that comes into the discussion of whether to issue an exception for unbundling. Bundling makes many things easier for upstreams and makes many things harder for distributions and has both positive and negative effects for end-users. So there's often a fight between what upstream wants and what the distribution wants. We often end up patching locally to work around a recalcitrant upstream.
If you have more rationale on why this should be granted an exception, this would be a good time to add that here. You can use the https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Standard_questions to see what kinds of information might be useful in making your case.
The tool is designed to be self-contained for its intended use. Upstream is willing to maintain it, and fix bugs reported to them. We can be a provider of this tool for end users, and let upstream maintain it. I don't have any other rationale other than this.
Thanks for your reply and wonderful explanation.
Replying to [comment:2 shakthimaan]:
The tool is designed to be self-contained for its intended use. Upstream is willing to maintain it, and fix bugs reported to them. We can be a provider of this tool for end users, and let upstream maintain it. I don't have any other rationale other than this. Thanks for your reply and wonderful explanation.
I second Toshio's argument, which is basically what I'd been arguing in the review BZ. If people want to use what upstream provides, that's fine, but if it is to be integrated into the distribution, it will not be self-contained. Using upstream's headers will potentially make their software more usable by more people, probably easier to maintain, and certainly easier for more people to debug.
At today's FPC meeting we voted not to allow this exception (+1:0, 0:0, -1:6)
From the information given, it appears that this is a matter of the header files being used unconditionally when there's only certain platforms that they are needed on. If that's the extent of it, it should be something more like::
{{{
}}}
With a buildtime check that BLAH is satisfied when being built on this platform. Feel free to reopen/open a new exception request if the information we have is not the whole picture.
Login to comment on this ticket.