Bug 225301 - Merge Review: automake17
Merge Review: automake17
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Nobody's working on this, feel free to take it
Fedora Package Reviews List
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-01-29 16:09 EST by Nobody's working on this, feel free to take it
Modified: 2012-02-29 09:16 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-02-29 09:16:45 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Nobody's working on this, feel free to take it 2007-01-29 16:09:02 EST
Fedora Merge Review: automake17

http://cvs.fedora.redhat.com/viewcvs/devel/automake17/
Comment 1 Karsten Hopp 2007-02-20 12:04:01 EST
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.
Comment 2 Ralf Corsepius 2007-02-20 13:32:52 EST
(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.
Comment 3 Karsten Hopp 2007-02-20 15:37:02 EST
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...
Comment 4 Karsten Hopp 2007-03-13 11:33:55 EDT
what's the review status here ? Is it approved ?
Comment 5 Patrice Dumas 2007-09-14 16:41:07 EDT
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.
Comment 6 Patrice Dumas 2007-09-14 16:48:27 EDT
In fact the Conflict is certainly right. But the Obsolete
should certainly be added.
Comment 7 Karsten Hopp 2007-09-17 08:07:57 EDT
fixed in automake17-1.7.9-9
Comment 8 Patrice Dumas 2007-09-17 17:12:02 EDT
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.
Comment 9 Karsten Hopp 2007-09-18 09:15:32 EDT
/usr/share/automake-1.7/install-sh is MIT afaik.
I've fixed the Obsoletes version
Comment 10 Karsten Hopp 2007-09-18 10:06:18 EDT
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.
Comment 11 Patrice Dumas 2007-09-18 15:03:57 EDT
(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.
Comment 12 Patrice Dumas 2007-09-18 15:07:06 EDT
(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.


Comment 13 Karsten Hopp 2007-09-19 08:56:57 EDT
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.
Comment 14 Patrice Dumas 2007-09-19 09:51:06 EDT
(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.
Comment 15 Kevin Fenzi 2008-03-02 13:45:22 EST
Patrice: Are you reviewing this? It seems so, so I am setting fedora-review: ?
If not, feel free to reset and unassign. 
Comment 16 Patrice Dumas 2008-03-02 16:22:01 EST
Resetting and unnassigning since I am in disagreement with the 
packager and I won't approve the Obsoletes < 1.8.
Comment 17 Karsten Hopp 2012-02-29 09:16:45 EST
I'll close this as noone seems to care

Note You need to log in before you can comment on or make changes to this bug.