On 7/26/06, Toshio Kuratomi <toshio@xxxxxxxxxxxxxxx> wrote:
On Wed, 2006-07-26 at 12:45 -0700, Christopher Stone wrote: > On 7/26/06, Toshio Kuratomi <toshio@xxxxxxxxxxxxxxx> wrote: > > On Wed, 2006-07-26 at 12:04 -0700, Christopher Stone wrote: > > > On 7/25/06, Ville Skyttä <ville.skytta@xxxxxx> wrote: > > > > On Mon, 2006-07-24 at 18:26 -0700, Christopher Stone wrote: > > > > > Also Ville insists on their being a %build section for an unknown > > > > > reason. > > > > > > > > I did provide a reason, you seem to choose to ignore it. > > > > > > Well you keep referencing a bug number with your argument and the > > > comments made in the bug you refer to seem to suggest my point of view > > > rather than yours. Basically the bug reporter simply did not know > > > what he was doing. So this bug that you refer to basically > > > invalidates your claim that there is a problem with not adding %build. > > > So you provide some reason, then invalidate this reason with a bug > > > number and therefore you provide an unknown or null or void or > > > canceled out reason. Kind of like when matter collides with > > > anti-matter... > > > > Bug#192422 is showing that specs without %build can trigger unexpected > > behaviour. The bug reporter did know what he was doing, he just didn't > > know that rpm had a bug in it that prevented it from working as > > expected. > > No, bug #192422 is showing that without %build a debuginfo package > will not be built. This is totally _expected_ behavior. > > See: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=192422#c11 > Really? Where's the documentation?
The documentation is here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=192422#c3 So it seems that the way the redhat-rpm-config package is set up, you must have a %build section to generate a debuginfo package. Since all php-pear packages are noarch and do not produce binaries, we do not need debuginfo packages, and therefore do not need a %build section. Secondly, it has been indicated that this design is hacky. Perhaps a bug filed against redhat-rpm-config can be filed to try and fix this hack in a better way.
If php were to fail to process a section anytime I put extra spaces after my php tag "<?php " would that be expected behaviour? Now if the php maintainer closed the bug saying, "Because of the way we coded php, that's the way it works" would it then be expected behaviour?
In php if you end your script file with "?> " (ie, you have a space after the >) then header information will be printed out and you will not be able to change the header tags after this point. This is expected behavior. In the same case as we have, the way redhat-rpm-config is set up, it is expected behavior that omitting %build will omit a debuginfo rpm. If this needs to be fixed then I would suggest filing a bug against redhat-rpm-config, not rpm.
> > > > So it's better to anticipate that there might be other unexpected things > > when shipping without %build (either there now or added in the future > > when the rpm maintainer decides: debuginfos do it this way, I might as > > well make feature X do it that way as well) rather than letting > > everything work for the trivial cases we're dealing with now and then > > suddenly expose another bug somewhere down the road. > > You are working off the false premise that there is unexpected > behavior in rpm. I am very highly doubtful that the rpm source code > is so pathetically bad that no body really knows what might happen > when certain things are added or removed from spec files. LOL. You are working off the false premise that it matters what the code says. If a program SegFaults, it's because the code says, please violate memory here. That doesn't mean that the user should expect the program to crash. jbj admits the code to create debuginfos is hacky. However, he doesn't propose that someone submit a patch to fix it; instead he closes it WONTFIX. rpm is littered with similar issues where the code doesn't do what the end-user expects. Attempting to stay away from issues that could trigger them is just good practice.
I think jbj is saying that it is not an rpm problem, it is a redhat-rpm-config problem. -- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging
