Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 230856 - autogen package is misconfigured
Summary: autogen package is misconfigured
Alias: None
Product: Fedora
Classification: Fedora
Component: autogen
Version: 9
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Debarshi Ray
QA Contact: Fedora Extras Quality Assurance
Whiteboard: Mispackaged bzcl34nup
Depends On:
Blocks: FE7Target
TreeView+ depends on / blocked
Reported: 2007-03-03 20:17 UTC by Bruce Korb
Modified: 2009-07-14 16:55 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2009-07-14 16:55:40 UTC

Attachments (Terms of Use)

Description Bruce Korb 2007-03-03 20:17:05 UTC
Description of problem:
Missing and misnamed files

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. install package
2. try to use AutoOpts automated option processing.
   The templates fail.  If you have source generated elsewhere,
   it still fails because the autoopts/options.h header is not
Actual results:

Expected results:

Additional info:

Comment 1 Paul F. Johnson 2007-03-03 23:47:55 UTC
Do you have the -devel subpackage installed?

Comment 2 Bruce Korb 2007-03-04 20:09:42 UTC
autogen itself is a development package.  Personally, I build and
install from sources.  It is other folks that have the problem
(specifically Ron Arts, plus anyone else who tried, failed and
did not bother to complain.)  Anyway, since anyone wanting autogen
is almost certainly going to want autogen-devel, it is hard to
understand the reason for separating them.  Even harder when you notice
that there are only (or: should only be) two files in the autogen-devel

Comment 3 Paul F. Johnson 2007-03-04 21:14:10 UTC
I know it's a development package!

The packaging rules for Fedora is that you have to have the headers and any .so
files and .pc files in a separate package - doesn't matter if there is only a
single .pc file, the rules goes that it needs it's own subpackage (if you look
at quite a few mono packages, you'll find the -devel subpackage has a single .pc
file in it)

In this respects, the package itself is not misconfigured.

Comment 4 Bruce Korb 2007-03-04 21:49:51 UTC
OK.  I see.  The problem is that both Ron Arts and I made the same
mistake of assuming that getting "autogen" was sufficient.  This,
then, is likely a more general problem:  if someone selects a package
that is not particularly useful without its "*-devel" companion,
then something needs to be triggered if the "yum" request omits it.

The packaging system is self-consistent, just prone to confusion
and misuse.  There should be an RFE for this.

Nevertheless, there is still an issue with not being able to invoke
"columns" as "columns" from within hundreds if not thousands of templates.
It _is_ a generic command line program, even if it comes from
the autogen package.  Heck, I just did a Google for "man page columns"
and the first section 1 man page was:
It looks very familiar to me....

Comment 5 Paul F. Johnson 2007-03-04 21:55:38 UTC
Only problem is that you end up with a circular dependency problem.

I'll seek advice on the columns problem

Comment 6 Bruce Korb 2007-03-04 22:06:28 UTC
RE: circular dependency:  I meant add a warning.  "autogen" would
not depend upon "autogen-devel", but rather, package "foo" implies
you'd probably like to have (but don't have to have) "foo-devel".
So, if you don't already have "foo-devel" and you are not requesting
both "foo" and "foo-devel", then maybe you might want to consider
"foo-devel", too.

Comment 7 Debarshi Ray 2008-03-31 14:23:07 UTC
Reassigning to myself since I own this package now.

Comment 8 Bug Zapper 2008-04-04 06:25:56 UTC
Fedora apologizes that these issues have not been resolved yet. We're
sorry it's taken so long for your bug to be properly triaged and acted
on. We appreciate the time you took to report this issue and want to
make sure no important bugs slip through the cracks.

If you're currently running a version of Fedora Core between 1 and 6,
please note that Fedora no longer maintains these releases. We strongly
encourage you to upgrade to a current Fedora release. In order to
refocus our efforts as a project we are flagging all of the open bugs
for releases which are no longer maintained and closing them.

If this bug is still open against Fedora Core 1 through 6, thirty days
from now, it will be closed 'WONTFIX'. If you can reporduce this bug in
the latest Fedora version, please change to the respective version. If
you are unable to do this, please add a comment to this bug requesting
the change.

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we are following is outlined here:

We will be following the process here: to ensure this
doesn't happen again.

And if you'd like to join the bug triage team to help make things
better, check out

Comment 9 Bruce Korb 2008-04-04 13:57:49 UTC
Despite the component name, "autogen", this is actually a bug report against
the Fedora packaging.  Specifically, you have strict definitions of which
sorts of things go into a base package and what other sorts of things go
into a whatever-devel package.  That is well and good and fine and all, but
autogen is one of probably a number of packages wherein it is extraordinarily
unlikely that someone would want the "autogen" package without also getting
the "autogen-devel" package.  It isn't that autogen depends on autogen-devel,
but rather you cannot do a whole lot with autogen without autogen-devel.
Useful work depends upon both.  Therefore, there needs to be a way to say,
"if you want package X, then you are far more likely than not to also want Y."
Once there is a way to say that, the autogen package will need to say it.

P.S. I submitted the bug but cannot change the version to something new.  Do you
want a new bug?

Comment 10 Tom "spot" Callaway 2008-04-04 21:46:49 UTC
If the maintainer agrees that autogen is useless without the autogen-devel bits
being present, then they can roll the -devel bits into the base package (and
Provide/Obsolete autogen-devel properly).

Comment 11 Bug Zapper 2008-05-14 02:39:44 UTC
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:

Comment 12 Debarshi Ray 2008-07-23 01:24:27 UTC
Currently Autogen is split into 3 parts in Fedora:
+ autogen (Requires: autogen-libopts)
+ autogen-libopts
+ autogen-libopts-devel (Requires: autogen-libopts)

The reason for the split is mentioned here and it looks like Debian
( also has a similar division.

Bruce is probably suggesting that we merge autogen-libopts and
autogen-libopts-devel into a single autogen-libopts. Lets take the example of
Anjuta (, which uses Autogen while building and at run-time.
It only needs autogen and autogen-libopts, and not autogen-libopts-devel, for
its needs.

So should we still perform the merge or let autogen-libopts-devel be a separate

Comment 13 Bruce Korb 2008-07-27 00:52:57 UTC
No, actually Bruce was talking about the separation of "autogen" and
"autogen-devel".  Without doing a careful analysis of which pieces went where,
the autogen collection of binaries requires the libopts shared library
("autogen-libopts").  Applications that use generated options (via the
"autogen-libopts-devel" template files and "autogen" executable), will also need
"autogen-libopts" to be installed.  When such apps are installed, they would
_not_ need either "autogen" or "autogen-libopts-devel".  Just and only the
shared library.  The full build of such a product would require all three.

So, assuming that "autogen-libopts-devel" includes the option templates (e.g.
option.tpl), this file is useless without autogen.  Thus,
"autogen-libopts-devel" really requires both "autogen" and "autogen-libopts".

What I chose to do for myself and my own releases was to say, "disk space is
cheap and it is not worth the bother to try to separate "libopts/autoopts" from
"autogen".  I also do not see a problem with providing alternate licenses to
specific source files, all bundled into one package.  I am not a lawyer, but 40
years of prior art seems to indicate that it is important to mark each and every
source file with a copyright notice line or two.  That implies that each file
stands on its own.  I do not want my autoopts using "clients" to fret over the
perceived "GPL virus".

I hope I'm being clear.  :-)

Comment 14 Debarshi Ray 2008-07-27 06:47:33 UTC
autogen has a runtime dependency on autogen-libopts, while autogen-libopts-devel
has a similar dependency on autogen-libopts.

These are the files in the autogen:

%doc ChangeLog
%doc NEWS
%doc TODO
%doc pkg/libopts/COPYING.gplv3

%dir %{_datadir}/%{name}

These are the files in autogen-libopts:

%doc pkg/libopts/COPYING.mbsd
%doc pkg/libopts/COPYING.lgplv3

These are the files in the autogen-libopts-devel:


%dir %{_includedir}/autoopts

Moreover autogen is tagged as GPLv3+. (Some files are licensed under GPLv2+.
Some files are licensed under GPLv2+.) autogen-libopts and autogen-libopts-devel
are tagged as LGPLv3+. (Although sources are dual licensed with BSD, some
autogen generated files are only under LGPLv3+. We drop BSD to avoid multiple
licensing scenario.)

So I guess the clients do not have to bother about the GPL virus, since the
libraries are separated out in LGPL-ed packages.

Package sources:


Comment 15 Debarshi Ray 2008-11-17 14:25:09 UTC
Bruce, ping?

Comment 16 Bruce Korb 2008-11-17 16:06:35 UTC
Debarshi, ack?

autogen-libopts-devel requires both autogen and autogen-libopts.
autogen requires autogen-libopts to run and autogen-libopts-devel to build.
autogen-libopts is required by any package that requires
autogen-libopts-devel to build.

Yes, indeedy, there is a circular dependency.  These packages
are co-dependent.  I refer you to comment #13.  One big ball of
wax may violate Red Hat guidelines, but it surely makes the
interdependency mess a lot more tractable.

That all now said, I think you all get to decide what works best
for your distribution.  Just the one caveat that if folks wind up
installing autogen and autogen-libopts and are not warned to install
autogen-libopts-devel, you will see some complaints.

Comment 17 Bug Zapper 2009-06-09 22:29:29 UTC
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here:

Comment 18 Bug Zapper 2009-07-14 16:55:40 UTC
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

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