From owner-cvs-all Thu Oct 25 0:36:31 2001 Delivered-To: cvs-all@freebsd.org Received: from ipcard.iptcom.net (ipcard.iptcom.net [212.9.224.5]) by hub.freebsd.org (Postfix) with ESMTP id 8A01F37B405; Thu, 25 Oct 2001 00:36:20 -0700 (PDT) Received: from vega.vega.com (h6.229.dialup.iptcom.net [212.9.229.6]) by ipcard.iptcom.net (8.9.3/8.9.3) with ESMTP id KAA42134; Thu, 25 Oct 2001 10:36:14 +0300 (EEST) (envelope-from sobomax@FreeBSD.org) Received: from FreeBSD.org (big_brother.vega.com [192.168.1.1]) by vega.vega.com (8.11.6/8.11.3) with ESMTP id f9P7YkU16818; Thu, 25 Oct 2001 10:34:46 +0300 (EEST) (envelope-from sobomax@FreeBSD.org) Message-ID: <3BD7C115.63F75C69@FreeBSD.org> Date: Thu, 25 Oct 2001 10:36:53 +0300 From: Maxim Sobolev Organization: Vega International Capital X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en,uk,ru MIME-Version: 1.0 To: John Baldwin Cc: cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org, obrien@FreeBSD.org Subject: Re: cvs commit: ports/devel/automake Makefile distinfo pkg-plist References: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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