please check automake16-1.6.3-9 or later as it has fixes for the most common
review issues.

The install-info scriptlet is certainly wrong, it should certainly
be automake16.info. Moreover, I suggest dropping the .gz in these 
scriptlets.

There should be a comment explaining why there is a plain ./configure
and not %configure.

make check should be in %check

I am not completely sure that that package should explicitly Conflict 
with automake 1.6.3: there could be no real conflict. 

Created attachment 150342 [details]
complete Makefile.in patching when using automake16.texi

- install-info has been fixed by Florian LaRoche.
- comment about ./configure added
- make check moved to %check

I don't think your makefile changes are required as we don't ship dvi stuff
afaik. Applied anyway.

I don't think the
Obsoletes:  automake = 1.6.3
is right either. In my opinion there shouldn't be anything 
related with automake = 1.6.3.

the Obsolete: is required as we shipped automake-1.6.3 in older releases and 
automake16 needs to replace that.

Is it really true? It means that people having automake on a
previous release won't have the latest automake. I am not
sure that it is what we want. If it was possible to say to
rpm to install automake16 and update to current automake 
version it would be even better, but that is not the case.
In any case using a precise version is not right. What about
if a use has 1.6.2 installed? He will get the latest, while
with 1.6.3 it goes to automake16. Isn't that wrong?

Created attachment 174101 [details]
finish Makefile.in patching

For an unknown reason, part of my patch above wasn't 
applied.

We don't ship any dvi files and it doesn't really matter. But I've added this
for completeness in -13.
Please close this bugzilla if everything else looks ok.

Almost. There is still the automake = 1.6.3 obsoletion that
annoys me. I sent a mail on -devel, we'll see what people respond.
And if nobody responds for some day I'll repost on -packaging.

The Obsolete is right, as explained by Michael Schwendt, it
allows to rename the package while still updating to the latest
version.

Still 2 issues remaining:
Is the 
Buildrequires:  autoconf >= 2.52
needed? I don't think so. 

Otherwise could you please precise what is covered by MIT
in a comment for example? 
In my opinion the documentation is under OFSFDL, this should
be added, with a comment.

autoconf is definitely required tor the self tests. You'll get >50 failures
otherwise. 
I'd prefer not to start listing which files are under which license. When
someone has concerns about the used licenses he/she would have to check every
file anyhow.

Can you point me to a wiki page backing up your request for that ?

You're right about OFSFDL, I've added that to the license list

(In reply to comment #12)
> autoconf is definitely required tor the self tests. You'll get >50 failures
> otherwise. 

Right.

> I'd prefer not to start listing which files are under which license. When
> someone has concerns about the used licenses he/she would have to check every
> file anyhow.

Indeed. My issue is that I don't see any file under the MIT license.
All that I see are in GPL.

I guess that it is install-sh which is MIT. A comment in 
the spec file would be good.

APPROVED.

You can close this bug.

thanks, closing...