Bug 225300 - Merge Review: automake16
Merge Review: automake16
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Patrice Dumas
Fedora Package Reviews List
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-01-29 16:08 EST by Nobody's working on this, feel free to take it
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version: automake16-1.6.3-14
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-10-04 09:06:33 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
pertusus: fedora‑review+


Attachments (Terms of Use)
complete Makefile.in patching when using automake16.texi (2.27 KB, patch)
2007-03-18 18:44 EDT, Patrice Dumas
no flags Details | Diff
finish Makefile.in patching (728 bytes, patch)
2007-08-27 14:32 EDT, Patrice Dumas
no flags Details | Diff

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

http://cvs.fedora.redhat.com/viewcvs/devel/automake16/
Comment 1 Karsten Hopp 2007-02-20 09:25:45 EST
please check automake16-1.6.3-9 or later as it has fixes for the most common
review issues.
Comment 2 Patrice Dumas 2007-03-18 18:42:00 EDT
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. 
Comment 3 Patrice Dumas 2007-03-18 18:44:05 EDT
Created attachment 150342 [details]
complete Makefile.in patching when using automake16.texi
Comment 4 Karsten Hopp 2007-03-22 10:18:22 EDT
- 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.
Comment 5 Patrice Dumas 2007-03-24 22:09:20 EDT
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.
Comment 6 Karsten Hopp 2007-04-16 08:38:57 EDT
the Obsolete: is required as we shipped automake-1.6.3 in older releases and 
automake16 needs to replace that.
Comment 7 Patrice Dumas 2007-04-22 17:31:23 EDT
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?
Comment 8 Patrice Dumas 2007-08-27 14:32:26 EDT
Created attachment 174101 [details]
finish Makefile.in patching

For an unknown reason, part of my patch above wasn't 
applied.
Comment 9 Karsten Hopp 2007-08-28 06:11:39 EDT
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.
Comment 10 Patrice Dumas 2007-08-28 07:31:40 EDT
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.
Comment 11 Patrice Dumas 2007-09-14 16:10:07 EDT
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.
Comment 12 Karsten Hopp 2007-09-17 09:57:46 EDT
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
Comment 13 Patrice Dumas 2007-09-17 16:53:10 EDT
(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.
Comment 14 Patrice Dumas 2007-09-21 14:39:23 EDT
I guess that it is install-sh which is MIT. A comment in 
the spec file would be good.

APPROVED.
Comment 15 Patrice Dumas 2007-10-04 04:16:01 EDT
You can close this bug.
Comment 16 Karsten Hopp 2007-10-04 09:06:33 EDT
thanks, closing...

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