[Bug 230856] autogen package is misconfigured

bugzilla at redhat.com bugzilla at redhat.com
Sun Jul 27 00:52:57 UTC 2008


Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.

Summary: autogen package is misconfigured


https://bugzilla.redhat.com/show_bug.cgi?id=230856





------- Additional Comments From bkorb at gnu.org  2008-07-26 20:52 EST -------
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.  :-)

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.




More information about the fedora-triage-list mailing list