Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 24 Oct 2001 14:31:49 -0700 (PDT)
From:      John Baldwin <jhb@FreeBSD.org>
To:        Maxim Sobolev <sobomax@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:  <XFMail.011024143149.jhb@FreeBSD.org>
In-Reply-To: <200110242104.AAA93434@ipcard.iptcom.net>

next in thread | previous in thread | raw e-mail | index | archive | help

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.

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?

-- 

John Baldwin <jhb@FreeBSD.org> -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/

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?XFMail.011024143149.jhb>