On Fri, 22 Sep 2006, Steve Dickson wrote:
Toshio Kuratomi wrote:
You haven't addressed Paul's point that it's easier for us (we're
supposed to be knowledgable packagers, right?) to detect these errors
than for people downloading the SRPM and rebuilding in their local
environment to do so.
In this particular case it wouldn't be ways for either them or us
because the errors are undetectable... but I truly doubt their
locally build rpm will end up on thousands of desktop via yum
marrying corrupting machines as they go. The point being we should put
in safeguards in that will stop us from sending out corrupted rpms
and by adding those packages we are doing just that... imho..
If the errors are undetectable, then I consider it all the more reason
for you to add BRs for autoconf/automake. As stated previously, your case
isn't really any different than any other missing BuildReqs that cause
weird behavior in the resultant packages.
From an earlier email:
Jesse Keating wrote:
> I don't accept your claim that these are the most common used packages
> to build our rpms.
These tools have been around since the early days of UNIX and have been
used every since... so whether you accept that or not is.... well...
indifferent...
Unless you want to s/UNIX/Linux/, Toshio seemed to discount this claim.
But, regardless of how old they are, age does not equal importance. I
have a relatively meager package load (11), but only one of my packages
uses autoconf. I asked Spot, as he has more packages (101); only three
use autoconf or automake. A small sampling, for sure, but I can't help
but wonder if it's at least vaguely representative.
You also haven't addressed Jesse's points that
this applies to many other packages besides autoconf and automake (what
makes this case exceptional?)
They stop undetectable RPM corruption...
That's generally the point of correctly defining your BuildReqs.
or his point that part of being a packager
is to look over the build logs to be sure your package not only built
but built the way you expected it to.
And me tell why its not a broken build system when we have to scour over
successful build logs looking for data corrupters...
Sounds more like broken packages, personally.
If you think that autoconf and automake should require an extra level of
error checking, you might also consider writing a test for rpmlint that
checks patches for changes to Makefile.am, configure.ac, etc, and if it
finds some, makes sure that the spec file calls autoconf, automake, or
autoreconf. This can benefit people who are not using our particular
buildsystem as well.
Or just add two very small, highly used packages to the buildroot. ;-)
Would you mind ennumerating "highly used?"
Jima
--
Fedora-maintainers mailing list
Fedora-maintainers@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-maintainers
--
Fedora-maintainers-readonly mailing list
Fedora-maintainers-readonly@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-maintainers-readonly
