Do you have the -devel subpackage installed?

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
package.

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.

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:
http://www.die.net/doc/linux/man/man1/columns.1.html
It looks very familiar to me....

Only problem is that you end up with a circular dependency problem.

I'll seek advice on the columns problem

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.

Reassigning to myself since I own this package now.

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.
http://fedoraproject.org/wiki/LifeCycle/EOL

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:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping 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 http://fedoraproject.org/wiki/BugZappers

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?

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).

Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

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
https://bugzilla.redhat.com/show_bug.cgi?id=432542#c1 and it looks like Debian
(http://packages.debian.org/sid/autogen) 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 (http://anjuta.org/), 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
identity?

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.  :-)

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 AUTHORS
%doc ChangeLog
%doc COPYING
%doc NEWS
%doc README
%doc THANKS
%doc TODO
%doc pkg/libopts/COPYING.gplv3
%{_bindir}/columns
%{_bindir}/getdefs
%{_bindir}/%{name}
%{_bindir}/xml2ag
%{_infodir}/%{name}.info.gz
%{_infodir}/%{name}.info-1.gz
%{_infodir}/%{name}.info-2.gz
%{_mandir}/man1/%{name}.1.gz
%{_mandir}/man1/columns.1.gz
%{_mandir}/man1/getdefs.1.gz
%{_mandir}/man1/xml2ag.1.gz

%dir %{_datadir}/%{name}
%{_datadir}/%{name}/stdoptions.def
%{_datadir}/%{name}/*.tpl


These are the files in autogen-libopts:

%doc pkg/libopts/COPYING.mbsd
%doc pkg/libopts/COPYING.lgplv3
%{_libdir}/libguileopts.so.*
%{_libdir}/libopts.so.*


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

%{_bindir}/autoopts-config
%{_datadir}/aclocal/autoopts.m4
%{_datadir}/aclocal/liboptschk.m4
%{_libdir}/libguileopts.so
%{_libdir}/libopts.so
%{_libdir}/pkgconfig/autoopts.pc
%{_mandir}/man1/autoopts-config.1.gz
%{_mandir}/man3/*

%dir %{_includedir}/autoopts
%{_includedir}/autoopts/options.h
%{_includedir}/autoopts/usage-txt.h


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: http://cvs.fedoraproject.org/viewcvs/rpms/autogen/devel/

Comments?

Bruce, ping?

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.

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: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

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.