Bug 432542 - Review Request: autogen - Automated text file generator
Summary: Review Request: autogen - Automated text file generator
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
high
medium
Target Milestone: ---
Assignee: Mamoru TASAKA
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-02-12 18:44 UTC by Debarshi Ray
Modified: 2010-11-18 16:34 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-02-28 02:57:50 UTC
Type: ---
Embargoed:
mtasaka: fedora-review+
j: fedora-cvs+


Attachments (Terms of Use)

Description Debarshi Ray 2008-02-12 18:44:15 UTC
Spec URL: http://rishi.fedorapeople.org/autogen.spec
SRPM URL: http://rishi.fedorapeople.org/autogen-5.9.4-1.fc8.src.rpm


Description:

AutoGen is a tool designed to simplify the creation and maintenance of
programs that contain large amounts of repetitious text. It is especially
valuable in programs that have several blocks of text that must be kept
synchronised.

Comment 1 Debarshi Ray 2008-02-12 19:03:20 UTC
Koji: http://koji.fedoraproject.org/koji/taskinfo?taskID=419598

I inherited this package from Paul F. Johnson few days back. Since this was last
updated a year ago, I would like to pass this through a review.

Important changes:

+ Package split into autogen, libopts, and libopts-devel to avoid multiple
licensing scenario -- AutoOpts (or libopts) is BSD or LGPLv3+; while the rest of
AutoGen is GPLv3+  with some portions being GPLv2+. AutoGen's GPLv2+ portions
are being redistributed as GPLv3+.

Debian also has a similar breakup.

+ Dropped 'Obsoletes: libopts ...' because the libopts source package was
retired  and superseded by autogen during FC-5 and according to the Naming
Guidelines they should not be carried any further.

What should be done to smoothen the change caused by the splitting of autogen as
stated above?

Comment 2 Debarshi Ray 2008-02-12 19:06:14 UTC
Bumping priority because:

+ This was never built on PPC64 for no particular reason, it seems.
+ Prevents packages like Anjuta from getting built for PPC64.


Comment 3 Mamoru TASAKA 2008-02-12 20:00:07 UTC
(In reply to comment #2)
> Bumping priority because:
> 
> + This was never built on PPC64 for no particular reason, it seems.

There was a bug on ppc64 (not sure if it is really resolved:
bug 249138)

Comment 4 Debarshi Ray 2008-02-13 05:11:44 UTC
>> + This was never built on PPC64 for no particular reason, it seems.
 
> There was a bug on ppc64 (not sure if it is really resolved:
> bug 249138)

Looks like that was due to a build failure. However that was quite a few
releases back with autogen-5.8.9, and the latest release builds fine on PPC64.
Strangely there is no ExcludeArch in the Spec for PPC64.

Comment 5 Mamoru TASAKA 2008-02-16 17:17:43 UTC
Well, first of all, the version of bundled autoopts seems
31.0.6. Is it possible to submit a seperated autoopts review request?

Comment 6 Debarshi Ray 2008-02-16 18:25:51 UTC
Back in the days of FC-5 and FC-6 Fedora's libopts (or autoopts) package was
retired: http://cvs.fedoraproject.org/viewcvs/rpms/libopts/

Strangely the latest libopts tarball from upstream is versioned 27.6:
http://gnu.glug-nith.org/libopts/rel27.6/

At the same time, Debian ships a libopts package that bears the same EVRA as
autogen: http://packages.debian.org/experimental/libopts25 I took this option.
Remember due to the multiple licensing scenario we have to separate the libopts
(or autoopts) portion from the rest of autogen.

What do you suggest?


Comment 7 Debarshi Ray 2008-02-16 18:47:47 UTC
There was also a autogen-manuals package according to the Spec in CVS. According
to the %changelog, which is quite old, it was created to prevent some sort of
conflict on F-7. The reason for this conflict is unclear to me. Therefore, I
dropped it.

It looks to me that the *.autogen suffix is not required because no other
package seems to provide binaries of the same name. If that is so, we can drop
the dependency on %{_sbindir}/alternatives.

What do you think?

Comment 8 Mamoru TASAKA 2008-02-17 16:11:31 UTC
(In reply to comment #6)
> Strangely the latest libopts tarball from upstream is versioned 27.6:
> http://gnu.glug-nith.org/libopts/rel27.6/
> 
> At the same time, Debian ships a libopts package that bears the same EVRA as
> autogen: http://packages.debian.org/experimental/libopts25 I took this option.
> Remember due to the multiple licensing scenario we have to separate the libopts
> (or autoopts) portion from the rest of autogen.
> 
> What do you suggest?
  This is *only my opinion*
  I think that if you want to name the libopts related subrpm as "libopts"
  the version should be 31.0.6 (as  autoopts-config --version surely
  returns this value)
  texlive maintainers use this method (i.e. they allow different versions
  for subpackage), however I really don't want this.

  _IMO_ it is better that libopts related packages are named to show explicitly
  that they are subpackages of autogen, i.e. they should be 
  autogen-libopts-devel, for example (as we actually did so in tetex age)
  with the same EVR as autogen main package.


(In reply to comment #7)
> It looks to me that the *.autogen suffix is not required because no other
> package seems to provide binaries of the same name. If that is so, we can drop
> the dependency on %{_sbindir}/alternatives.
  If you don't know why alternatives is used here (note that I
  don't know either) it should just be dropped.



Comment 9 Debarshi Ray 2008-02-21 03:01:54 UTC
>   _IMO_ it is better that libopts related packages are named to show explicitly
>   that they are subpackages of autogen

I like this.

>   If you don't know why alternatives is used here (note that I
>   don't know either) it should just be dropped.

Alright.


Comment 11 Mamoru TASAKA 2008-02-22 16:55:58 UTC
For 5.9.4-2:

* autogen-manuals
  - new autogen package should "obsolete" this package.

? BR: chrpath
  - Well, would you try to remove rpath by not using chrpath?
    ("Removing Rpath" of
      http://fedoraproject.org/wiki/Packaging/Guidelines )
    Using chrpath should be considered as a last resort..

    Usually modifying libtool (or make LIBTOOL=%{_bindir}/libtool)
    removes rpath.

* License tag
  (See License-check.log)
  - Actually as %{_includedir}/autoopts/options.h (and so on)
    is LGPLv3+, "BSD or" part must be deleted.

* defattr
  - We now recommend %defattr(-,root,root,-)

* pkgconfig file
  - Well, autoopts.pc file contains
-------------------------------------------------------------
    11  ldopts="-Wl,-R"
    25  Libs:           -Wl,-R/usr/lib -L/usr/lib -lopts
-------------------------------------------------------------
    "-Wl,-R" sets rpath and this must be deleted.

! multilib conflict
  - autoopts/autoopts-config.in contains 
-------------------------------------------------------------
    20        libdir="@libdir@"
-------------------------------------------------------------
    or so, which differs between on 32bit arch and on 64bit arch.
    So this causes multilib conflict. Please try to resolve this
    conflict.
    http://fedoraproject.org/wiki/PackagingDrafts/MultilibTricks

* Undefined non weak symbols
  - libguileopts.so has undefined non-weak symbols
    From rpmlint (on i386):
-------------------------------------------------------------
autogen-libopts.i386: W: undefined-non-weak-symbol
/usr/lib/libguileopts.so.0.0.1 scm_i_master_freelist
autogen-libopts.i386: W: undefined-non-weak-symbol
/usr/lib/libguileopts.so.0.0.1 scm_i_master_freelist2
autogen-libopts.i386: W: undefined-non-weak-symbol
/usr/lib/libguileopts.so.0.0.1 scm_cells_allocated
autogen-libopts.i386: W: undefined-non-weak-symbol
/usr/lib/libguileopts.so.0.0.1 scm_i_freelist
autogen-libopts.i386: W: undefined-non-weak-symbol
/usr/lib/libguileopts.so.0.0.1 scm_i_freelist2
autogen-libopts.i386: W: undefined-non-weak-symbol
/usr/lib/libguileopts.so.0.0.1 scm_gc_for_newcell
autogen-libopts.i386: W: undefined-non-weak-symbol
/usr/lib/libguileopts.so.0.0.1 gh_eval_str
-------------------------------------------------------------
    ( you can check this also by "ldd -r /usr/lib/libguileopts.so")

    libguileopts.so is in -devel package, i.e. used for linkage
    so leaving these symbols is not allowed because this causes
    linkage failure.

* scriptlets
  - For /sbin/install-info, for some reason Fedora requests
    to use
--------------------------------------------------------------
/sbin/install-info %{_infodir}/%{name}.info %{_infodir}/dir || :
                                         ^^^^
--------------------------------------------------------------
    http://fedoraproject.org/wiki/Packaging/ScriptletSnippets

Comment 12 Debarshi Ray 2008-02-24 17:34:21 UTC
(In reply to comment #11)

> * autogen-manuals
>   - new autogen package should "obsolete" this package.

Fixed.
 
> ? BR: chrpath
>   - Well, would you try to remove rpath by not using chrpath?
>     ("Removing Rpath" of
>       http://fedoraproject.org/wiki/Packaging/Guidelines )
>     Using chrpath should be considered as a last resort..

+ there is no --disable-rpath option in configure
+ using sed to modify libtool as shown in Wiki causes build failure

Is it worth trying to modify the code/Makefiles as mentioned in the Wiki? I did
not try it because they say it is "not always easy or sane to do".

> * License tag
>   (See License-check.log)
>   - Actually as %{_includedir}/autoopts/options.h (and so on)
>     is LGPLv3+, "BSD or" part must be deleted.

Changed dual licensing of autogen-libopts-devel by dropping BSD.
 
> * defattr
>   - We now recommend %defattr(-,root,root,-)

Fixed.
 
> * pkgconfig file
>   - Well, autoopts.pc file contains
> -------------------------------------------------------------
>     11  ldopts="-Wl,-R"
>     25  Libs:           -Wl,-R/usr/lib -L/usr/lib -lopts
> -------------------------------------------------------------
>     "-Wl,-R" sets rpath and this must be deleted.

Fixed.

> ! multilib conflict
>   - autoopts/autoopts-config.in contains 
> -------------------------------------------------------------
>     20        libdir="@libdir@"
> -------------------------------------------------------------
>     or so, which differs between on 32bit arch and on 64bit arch.
>     So this causes multilib conflict. Please try to resolve this
>     conflict.
>     http://fedoraproject.org/wiki/PackagingDrafts/MultilibTricks

Ok. However, some pkgconfig files (eg., cairo.pc) have:
[...]
libdir=/usr/lib64
[...]
Libs: -L${libdir} -lcairo
[...]
 
Since the above write-up is a draft, I just want to confirm from you.

> * Undefined non weak symbols
>   - libguileopts.so has undefined non-weak symbols

Fixed.

> * scriptlets
>   - For /sbin/install-info, for some reason Fedora requests
>     to use

Fixed.

Spec: http://rishi.fedorapeople.org/autogen.spec
SRPM: http://rishi.fedorapeople.org/autogen-5.9.4-3.fc8.src.rpm

Koji: http://koji.fedoraproject.org/koji/taskinfo?taskID=466283

Comment 13 Mamoru TASAKA 2008-02-24 18:12:43 UTC
I have not checked this yet, however I just write some comments

(In reply to comment #12)
> > ? BR: chrpath
> >   - Well, would you try to remove rpath by not using chrpath?
> >     ("Removing Rpath" of
> >       http://fedoraproject.org/wiki/Packaging/Guidelines )
> >     Using chrpath should be considered as a last resort..
> 
> + there is no --disable-rpath option in configure
> + using sed to modify libtool as shown in Wiki causes build failure
> 
> Is it worth trying to modify the code/Makefiles as mentioned in the Wiki? I did
> not try it because they say it is "not always easy or sane to do".

- Actually
------------------------------------------------------------------
make %{__smp_mflags} LIBTOOL=%{_bindir}/libtool
------------------------------------------------------------------
  removed rpath as expected (please check the result of
  http://koji.fedoraproject.org/koji/taskinfo?taskID=466340
  http://koji.fedoraproject.org/koji/taskinfo?taskID=466331
  )
  

> 
> > * License tag
> >   (See License-check.log)
> >   - Actually as %{_includedir}/autoopts/options.h (and so on)
> >     is LGPLv3+, "BSD or" part must be deleted.
> 
> Changed dual licensing of autogen-libopts-devel by dropping BSD.
  - Also the license of autogen-libopts should be changed to
    just LGPLv3+ as the libraries in -libopts uses the header files
    in issue.
 
> > ! multilib conflict
> >   - autoopts/autoopts-config.in contains 
> > -------------------------------------------------------------
> >     20        libdir="@libdir@"
> > -------------------------------------------------------------
> >     or so, which differs between on 32bit arch and on 64bit arch.
> >     So this causes multilib conflict. Please try to resolve this
> >     conflict.
> >     http://fedoraproject.org/wiki/PackagingDrafts/MultilibTricks
> 
> Ok. However, some pkgconfig files (eg., cairo.pc) have:
> [...]
> libdir=/usr/lib64
> [...]
> Libs: -L${libdir} -lcairo
> [...]
>  
> Since the above write-up is a draft, I just want to confirm from you.
  - pkgconfig files are no problems because they uses different
    directories between 32 bits <-> 64 bits (%{_libdir}/pkgconfig,
    not /usr/lib/pkgconfig).

   On the other hand it must be checked that 64 bits pkgconfig file does not
   use /usr/lib but uses /usr/lib64 correctly.


Comment 14 Debarshi Ray 2008-02-24 19:26:58 UTC
(In reply to comment #13)

> ------------------------------------------------------------------
> make %{__smp_mflags} LIBTOOL=%{_bindir}/libtool

The Wiki does not mention this method, although I have seen it before. :-) Is
this preferred above using chrpath? I am asking because if it is so, then I need
to fix some of my existing packages.

Comment 15 Mamoru TASAKA 2008-02-25 01:55:51 UTC
I can say that using LIBTOOL=%{_bindir}/libtool is more preferable way to fix
rpath issues than to using Fedora specific chrpath binary and I saw several
people are actually using this method.

Comment 16 Debarshi Ray 2008-02-26 17:48:14 UTC
Spec: http://rishi.fedorapeople.org/autogen.spec
SRPM: http://rishi.fedorapeople.org/autogen-5.9.4-4.fc8.src.rpm

To omit unused direct shared library dependencies, I copied /usr/bin/libtool and
modified it as before.

Comment 17 Mamoru TASAKA 2008-02-27 08:11:31 UTC
(In reply to comment #11)
> For 5.9.4-2:
> 
> * autogen-manuals
>   - new autogen package should "obsolete" this package.

Well, I wrote so, however also now autogen can "provide"
autogen-manuals (= %{name}-%{version}).

Other things are okay.

------------------------------------------------------------------------
      This package (autogen) is APPROVED by me
------------------------------------------------------------------------

Comment 18 Debarshi Ray 2008-02-27 14:56:29 UTC
Package Change Request
======================
Package Name: autogen
Updated Fedora Owners: rishi
Updated Description: Automated text file generator
Updated Cvsextras Commits: yes

I inherited this from Paul F. Johnson and everything should already be in place,
but just in case...

Comment 19 Kevin Fenzi 2008-02-27 18:51:45 UTC
Yeah, everything seems in place to me... feel free to reset the flag if you need
anything. 

Comment 20 Debarshi Ray 2008-02-28 02:57:50 UTC
(In reply to comment #17)

> > * autogen-manuals
> >   - new autogen package should "obsolete" this package.
> 
> Well, I wrote so, however also now autogen can "provide"
> autogen-manuals (= %{name}-%{version}).

Fixed.

Comment 21 Anthony Green 2010-11-17 18:46:04 UTC
Package Change Request
======================
Package Name: autogen
New Branches: el6
Owners: green
InitialCC: 

Please branch this for el6. 

Thanks,

AG

Comment 22 Jason Tibbitts 2010-11-18 16:34:09 UTC
Git done (by process-git-requests).


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