On 28 Jun 2000, Alexandre Oliva wrote:
> On Jun 28, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote:
>
> > Now I understand Cygnus does not package forest
>
> Cygnus does. It is GNU that doesn't. So this change is more
> important for GNU developers in general than for Cygnus' customers.
> I'm sorry I didn't make this clear from the beginning. I hadn't
> realized it myself when I re-started this discussion.
Sorry, but I just do not see the logic in that argument. If some
tool has not been updated for 5 years, what are the chances
someone if going to switch to the new autoconf and expect everything
to work exactly the same way?
As far as our tree goes, the only way this argument makes sense
is if we import a 5 year old package into devo. In that
case, it is someone at cygnus that will need to do the work
to fix the old configure script so that it works with the
new autoconf.
I can see the logic in the argument that we (cygnus) would not
want people to use 2.13 in some places and 2.50 in other
places of out own tree, but that just means that we would
need to update all the configure scripts in devo at once
or just keep using 2.13 for some amount of time and then
switch them all over to 2.50. What problem is not solved
by either of these approaches?
> Mo> If you go back to the old way of doing it, then I doubt it will
> Mo> ever get changed.
>
> > I share you pessi^H^H^H^H^H impression.
>
> :-)
>
> I too fear we'll never be able to drop the old behavior, since there
> are packages out there that haven't had update releases for 5 years or
> more. We shouldn't expect such packages to disappear, so, it would
> not be unreasonable to retain some behavior in common with them. But
> I probably wouldn't fight for that in, say, two years' time.
I don't understand how you can make the claim that switching back is
"more important for developers in general than for Cygnus".
I can see how it is important to use, it means we will
not have to update any configure scripts for another 2 years.
Mo DeJong
Red Hat Inc
