On Mon, 2004-08-02 at 11:03, Pawel Salek wrote: > On 08/02/2004 06:40:34 AM, Colin Walters wrote: > > On Sun, 2004-08-01 at 08:57 -0700, Steve G wrote: > > > Hi, > > > > > > The new automake 1.9 breaks several packages. > > > > A package should *always* call a specific version of automake. If a > > package directly invokes "automake", that's a bug. It should instead > > call automake-1.8, automake-1.4, whatever is known to work. > > What if a package is known to work with all released automake versions: > Should it still hardcode one of them? I have a feeling it it is not a > good idea: will it not force users to have all possible versions of > automake installed just in case? Well, the question is not whether it is known to work with all released versions of automake, the question is whether it will work with all unreleased versions of automake... Until the automake maintainers make a commitment to backwards compatibility, there is no way you can know that. (I think there is some convergence ... things are changing less now than they used to. But there still is no commitment to not breaking things at all.) I generally don't see a point in running a newer version of automake than the maintainer of the package has tested it with. The packages isn't going to take advantage of features of the newer automake. Preference: - Don't run automake at all. It's only necessary if some patch modifies the Makefile.am's in the package. (If you do have to run automake put a comment by the invocation indicating which patch is the culprit.) - Run the version of automake that the distributed package uses as automake-1.8 or whatever. - Run the newest version of automake in the distribution, test, and hardcode that into the specfile as automake-1.8 or whatever. Regards, Owen
Attachment:
signature.asc
Description: This is a digitally signed message part
