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
Attachment:
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
-- Fedora-maintainers-readonly mailing list Fedora-maintainers-readonly@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers-readonly
