[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Automake 2.50 migration strategy, as implemented



On Sat, 26 May 2001, Steve M. Robbins wrote:

> On Sat, May 26, 2001 at 04:27:41PM -0400, Ben Collins wrote:
> > On Sat, May 26, 2001 at 04:09:04PM -0400, Ben Pfaff wrote:
> > > I am currently uploading the new version of autoconf and
> > > autoconf2.13.  These attempt to automatically select the desired
> > > version of Autoconf utilities at the time they are run.  In my
> > > simple tests, they work well.  We'll see how they do in practice,
> > > but I suspect that, except for possible minor bugs in the
> > > wrappers, they will work well there too.
> > >
> > > All that autobuilder maintainers, etc., should need to do, is to
> > > make sure that they install autoconf2.13 as well as the new
> > > autoconf.  This should not be challenging because the new
> > > autoconf Recommends: autoconf2.13 for now.  (I intend to demote
> > > the recommendation to a suggestion, then remove it, over the next
> > > year or so, as it gradually becomes less necessary.)
> >
> > However, installing autoconf negates having a clean chroot for the
> > autobuilders. This means that packages with missing build-deps on
> > autoconf will succeed, even though they are technically broken.
> >
> > I suggest making that recommends a depends for now.
>
> Why wouldn't you just special-case autoconf in the autobuilder
> code?

I'm currently playing the "manual" i386 autobuilder because there seems to
be no running autobuilder, and it's very convenient that I can fetch the
packages using apt and that I know that dpkg-buildpackage will handle it
when I forgot a build dependency. I'm not happy about adding such special
treatments that make it harder to manually recompile packages when there's
no autobuilder available (and BTW: when a package has build dependencies
it's a serious violation of the policy when it needs another package like
in this case autoconf2.13 to build without declaring a build dependency).


> Most of us are not autobuilders.  I don't relish the thought of
> spending the next year telling dselect NOT to install autoconf2.13.

We have two choices:
1. sending bug reports on packages that break with the new autoconf to get
   the problems fixed
2. do these tricks with autoconf2.13

I do disagree with any solution that makes it harder to reproduce how the
autobuilders work - I want that my packages get built the same way in
both an autobuilder and by hand.

> -S

cu
Adrian

-- 
A "No" uttered from deepest conviction is better and greater than a
"Yes" merely uttered to please, or what is worse, to avoid trouble.
                -- Mahatma Ghandi



Reply to: