On Mon, 2005-10-31 at 15:22 +0100, Ralf Corsepius wrote: > On Mon, 2005-10-31 at 15:31 +0300, Dmitry Butskoy wrote: > > According to wiki/PackagingGuidelines, there is exceptions list for > > BuildRequires tag: > > > > > There is no need to include the following packages or their > > > dependencies as BuildRequires because they would occur too often. > > > These packages are considered the minimum build environment. > > > > > Autoconf and automake are not present in this list, therefore they must > > be specified in the BuildRequires tag. OTOH it looks as some basic > > tools... May be autoconf and automake should be included in the > > exception list too? > Never. > > Any package requiring them is _broken_. Such bugs should be reported > upstream and fixed there. > I agree that they should be reported upstream. But what happens until upstream makes their next release? No movement on the package? Or truly horrid, unreviewable, thousand-line patches of Makefile.in's? Whether running autoconf or patching Makefile.in's is more broken is not clear. > Also running any autotool as part of building a package imposes > non-negligible risks to silently break packages. > Can this be fixed by pegging which version of automake is needed? $ head -1 ./Makefile.in # Makefile.in generated by automake 1.7.9 from Makefile.am. edit the spec to include BuildRequires: automake17 I don't know what problems you are referring to so I'm just taking a stab in the dark at a possible solution. -Toshio
Attachment:
signature.asc
Description: This is a digitally signed message part