automake17-1.7.9-8 has quite a few fixes, although self checks are currently
disabled. I need to look at some failures when I have spare time.

(In reply to comment #1)
> automake17-1.7.9-8 has quite a few fixes, although self checks are currently
> disabled. I need to look at some failures when I have spare time.
Frankly speaking, I would not apply any fixes, but ship a plain vanilla FSF
automake. automake-1.7.x is dead for years and anybody still using it deserves
to feel the pain.

Whoops, maybe we should continue in German to avoid misunderstandings ;-)

Fixes are only in the spec file, there's only one patch for the self checks, but
those are currently disabled.

  Gruesse aus Stuttgart...

what's the review status here ? Is it approved ?

The Conflict should certainly be an obsolete. And maybe an
Obsolete for 1.7.9?

Seems that the texinfo-tex BR is needed for a test? It should
be said so in a comment.

The BR autoconf is needed. It is a bit strange in my opinion,  
but it is upstream choice.

License is wrong.

README AUTHORS THANKS missing in %doc

Also a comment for ./configure should be nice.

And lastly it would be nice to have the info file available. I can
try a patch for that if you want to.

In fact the Conflict is certainly right. But the Obsolete
should certainly be added.

fixed in automake17-1.7.9-9

I think that the Obsoletes should be with
Obsoletes:  automake = 1.7.9

I have checked that when rerunning automake-1.7, the
Makefile.in files are not the same, in the new ones there are other
variables. But those variables look suspiciously like variables
introduced in recent automake (1.9 or 1.10). So it 
is certainly right as is.

The check part should be in a %check section. Currently
it is in comment, but it would certainly be better to put a
#%check
at the beginning of the comments, or even
%check
to avoid forgetting.

I still  don't see any file under the MIT license.

/usr/share/automake-1.7/install-sh is MIT afaik.
I've fixed the Obsoletes version

Stepan Kasal suggested using checking for versions  < 1.8 to catch all upgrades
from automake-1.7.*.
It would also match if automake-1.6.* is still installed, but that should be
replaced by automake16 anyhow.

Something like
Conflicts:  automake < 1.8
Obsoletes:  automake < 1.8

would disallow concurrent installation of automake17 with automake-1.6.* as 
well as automake-1.7.* but allows installation of automake16 and automake17.
I think I'll change it accoring to his suggestions.

(In reply to comment #10)
> Stepan Kasal suggested using checking for versions  < 1.8 to catch all upgrades
> from automake-1.7.*.
> It would also match if automake-1.6.* is still installed, but that should be
> replaced by automake16 anyhow.
> 
> Something like
> Conflicts:  automake < 1.8
> Obsoletes:  automake < 1.8

The Conflict is not useful, since the Obsolete will cause the
older automake to be removed.

> would disallow concurrent installation of automake17 with automake-1.6.* as 
> well as automake-1.7.* but allows installation of automake16 and automake17.
> I think I'll change it accoring to his suggestions.

But then if you have automake-1.6.3 installed, you have 2
package that obsolete it, automake16 and automake17. I am not sure
that it is right. 
Maybe
Obsoletes:  automake = 1.7.1, automake = 1.7.2, automake = 1.7.3
Obsoletes:  automake = 1.7.4, automake = 1.7.5, automake = 1.7.6
Obsoletes:  automake = 1.7.7, automake = 1.7.8, automake = 1.7.9

It is ugly, but may be more correct.

(In reply to comment #9)
> /usr/share/automake-1.7/install-sh is MIT afaik.

Very true. A comment would be nice, in my opinion. Not a
blocker.

a conflict makes sure that you can install automake-1.7 when automake17 is
installed. AFAIK rpm currently allows this.

I'd rather not go the road with the multiple obsoletes. I think using < 1.8
is as simple and clear as rpm currently allows. 
If someone uses an ancient automake version, I'm quite sure he/she knows how to
install it. 
This doesn't concern users of FC-2 and newer as they already have automake17 and
not automake-1.7, so I'd like to keep it like it currently is.

(In reply to comment #13)
> a conflict makes sure that you can install automake-1.7 when automake17 is
> installed. AFAIK rpm currently allows this.

Indeed (although in that case there will certainly be a file 
conflict). But since it is obsoleted this is not useful since
the  automake-1.7 will be removed in normal cases. Conflicts
should be avoided, but I won't make it a blocker. However,
it shouldn't conflict with anything else than 1.7*.

> I'd rather not go the road with the multiple obsoletes. I think using < 1.8
> is as simple and clear as rpm currently allows. 
> If someone uses an ancient automake version, I'm quite sure he/she knows how to
> install it. 

But it renders the Obsoletes of 1.6 by 16 unusefull. And are
you sure that the right version gets installed when there are
multiple Obsoletes? It is not that clear. Obsoleting only 1.7.9 
is clearer as it means that it simply was a rename. And your
argument holds if there is only 
Obsoletes: 1.7.9
If someone uses an ancient automake version, I'm quite sure he/she
knows how to install it.

> This doesn't concern users of FC-2 and newer as they already have automake17 and

I don't think that we should target some users, but try to do
as right as possible for those who have old automake versions 
installed, whatever version it is. In any case, this is not very 
important since the users who want to do such upgrades and keep
compat packages are likely to be knowledgable, but in any case we
should do the best we can.

Patrice: Are you reviewing this? It seems so, so I am setting fedora-review: ?
If not, feel free to reset and unassign. 

Resetting and unnassigning since I am in disagreement with the 
packager and I won't approve the Obsoletes < 1.8.

I'll close this as noone seems to care