Date: Thu, 25 Oct 2001 10:36:53 +0300 From: Maxim Sobolev <sobomax@FreeBSD.org> To: John Baldwin <jhb@FreeBSD.org> Cc: cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org, obrien@FreeBSD.org Subject: Re: cvs commit: ports/devel/automake Makefile distinfo pkg-plist Message-ID: <3BD7C115.63F75C69@FreeBSD.org> References: <XFMail.011024143149.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
John Baldwin wrote: > > On 25-Oct-01 Maxim Sobolev wrote: > > On Wed, 24 Oct 2001 12:46:41 -0700, David O'Brien wrote: > >> [portmgr CC'ed due to importancy of this port to the overall ports > >> infrastructure] > >> > >> You did not address your plans on when/how this port will return to 1.5. > >> We cannot put our head in the sand on this one (unlink libtool, this does > >> included new applicable functionality). > >> > >> Please list the ports that broke so they may be addressed. Many of the > >> ports that depend on automake probably really don't in truth need it. > >> Any package that uses Makefile.am+automake is suppose to supply a built > >> Makefile.in. > >> > >> Automake 1.5 is now needed for Binutils and GCC work, so are we either > >> need an upgrade plan, or an "automake-current" port. Actually, automake > >> should return to 1.5, and an automake14 port created (via repo copy). > >> The ports that cannot handle 1.5 can use the outdated version. > > > > The main problem here is that we don't have a way to reliable > > create a list of packages that can't work with newest > > automake/autoconf. Bento is still locked and only the one person > > who holds the keys is Satoshi. And I don't think that the problem > > is as fatal as you described, you (and any other maintainer with > > the similar problem) have at least two relatively simple workarounds: > > > > 1. Do a repo-copy and create a new automakeXX/autoconfXX ports, > > which will contain newest version of autocrap. Then you can > > use it as much as you like, without disturbing anybody. > > Errm, IMO, it would make more sense to do this in the way David proposed letting > the auto* ports take on the new version and making the auto*XX ports use the old > one, then just fix any breakages that come up. Doesn't bento do automated > builds of the packages? Just commit the changes, let the builds go through, > and fix the errors that pop up. We don't have a release real soon, so it > should be livable. Are you going to reply to those zillion "hey port XX broke because of auto*" PR, which will surely pop up if we do as you suggest? One of the strengths of the ports system is that in past such drive-by commits were carefully avoided and I don't think that it is a good idea to break this tradition and piss-off the users, especially considering that this problem could be resolved in a less destructive way. > Besides, if you have a problem with bento, you shouldn't use that to hold back > "progress", you should instead fix the root problem. Are we going to decide to > do no packages for 4.5 due to a bento problem if it works out that way? Yes, this need to be resolved, but for various reasons we aren't there yet. -Maxim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3BD7C115.63F75C69>