On Fri, 2006-09-22 at 19:57 -0400, Steve Dickson wrote:
> 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...
Actually, that's a falsehood. UNIX has been around much longer than
autoconf and automake. autoconf had just gained enough momentum when I
started using Linux in 1994 to look like it would indeed be able to
replace the previous generation of IMakefiles. automake wasn't even
born until later that year.
On a less tangential note, you're missing Jesse's point. Autoconf and
automake are used create the configure script and the Makefile.in's. As
Patrice and Tom Tromey were quick to assure us, automake is not needed
on the system where the dist tarball is unpacked and written. Our build
system doesn't use them on the vast majority of packages that it
creates.
Only when you change the build source files (Makefile.am, configure.ac,
etc) do you have to run the autotools to regenerate the build scripts.
At that point, it really is your responsibility to make sure you run the
programs from your spec file and BuildRequire them.
>
> > They should be viewed just like any other build requirement
> > and listed as such. For you its two auto* packages. To somebody else, it's
> > just pkgconfig, to yet another person its just intltool and gettext, so on
> > and so forth. The line has to be drawn somewhere and it has been drawn.
> Personally I think we should a bit more flexible and open to consider
> adding packages that have very real potential of stopping undetectable
> rpm corruption. Call me crazy... but I think thats a good idea verses
> sticking to a policy that allows corruption...
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. You also haven't addressed Jesse's points that
this applies to many other packages besides autoconf and automake (what
makes this case exceptional?) 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.
ad absurdum: because mono allows cross platform assemblies some mono
packages ship from upstream with prebuilt assemblies. If the mono
compile tools are not present on the system, these prebuilt assemblies
may be used to construct the package. This can open a security hole if
an upstream package includes assemblies that weren't actually generated
from the source code. Should we include the mono stack to cover this?
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.
-Toshio
signature.asc
Description: This is a digitally signed message part
--
Fedora-maintainers mailing list
Fedora-maintainers@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-maintainers
|
