[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Fedora-packaging] PHP guidelines



On Wed, 2006-07-26 at 12:45 -0700, Christopher Stone wrote:
> On 7/26/06, Toshio Kuratomi <toshio tiki-lounge com> wrote:
> > On Wed, 2006-07-26 at 12:04 -0700, Christopher Stone wrote:
> > > On 7/25/06, Ville Skyttä <ville skytta iki fi> 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?

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?

> >
> > 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.

-Toshio

Attachment: signature.asc
Description: This is a digitally signed message part


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]