net-libs/gnutls (and potentially other) packages currently RDEPEND sys-devel/autogen because they link to to libopts, a tiny 130k library. sys-devel/autogen in turn depends on dev-scheme/guile, together these are over 5megs. When building for an embedded system, and trying to trim down the install, 5megs is a fairly large bit. It would seem appropriate to split off a sys-libs/libopts which autogen depends on. Alternatively, this tiny library could simply be patched into gnutls for the tiny functionality it actually provides.
Alon Bar-Lev commented in the net-libs/gnutls Changelog; Revert autogen move, replace at RDEPEND as we configure gnutls to use system autogen. Thanks for radhermit.
Per what I wrote privately, tweaking software against upstream has maintenance costs we like to avoid. if autogen does not support this split it would be unwise to do this downstream.
5 MB (that could be merely excluded from the package install/copy) would actually be preferrable to the current situation where installing is basically impossible - the dependencies include Perl, Portage, and Python, among many others, some of which probably don't cross-compile at all.
again, you are missing the point. the problem in not doing so in single point in time, the problem is to maintain such patches for long term. the size of target is not important as you can strip what you need from it.
(In reply to Alon Bar-Lev from comment #4) > the size of target is not important as you can strip what you need from it. again, the size isn't a factor when it won't even build.
*** Bug 540038 has been marked as a duplicate of this bug. ***
According to http://savannah.gnu.org/support/index.php?108744#comment3 "libopts is separate from autogen in all distributions". Obviously, though not "all" since Gentoo has it only as part of autogen (but there is USE="-libopts"?), it sounds like other distributions have managed to keep them separate to the point where even a GnuTLS developer deems them separate packages. I'm sure it won't be a problem for Gentoo to fix this, too, one way or another.
gentoo as being source based distribution follows upstream as much as it can. as autogen package provides libopts, until upstream split libopts into separate package, it just makes sense that gentoo follows. the libopts USE flag within autogen is to install libopts SOURCES, so it has nothing to do with other packages use libopts. there is nothing to be fixed at downstream.
I don't quite see how Gentoo being source-based has anything to do with "most others" allegedly shipping them separately and we don't. Though other's wouldn't have to deal with compile-time issues, the ABI issues would be of the same kind. A few days ago we discussed the subject on IRC and it was proposed that we create a dedicated libopts package. I think it's fair to say that libopts is unlikely to get any major changes which would require maintenance of the split (if any changes at all) in the foreseable future. We'd then have GnuTLS et al depend on virtual/libopts which could be satisfied by split libopts or autogen. Extracting libopts from autogen (again, given the comment on Savanna I'm sceptical as to whether it hasn't actually already been done) should be but a matter of an appropriately crafted ebuild, based upon the autogen tarball.
what you suggest has maintenance overhead as it is not the way upstream provide the package. if autogen maintainer wishes to support this configuration he may do this. I do not think that doing so only for gnutls sake is important enough.
*** Bug 535782 has been marked as a duplicate of this bug. ***
I too think that extracting libopts from sys-devel/autogen to separate dev-libs/libopts package should be done. Recently dev-libs/libltdl was extracted from sys-devel/libtool: bug #528294 > I do not think that doing so only for gnutls sake is important enough. Seems you did not look at 'qgrep -N sys-devel/autogen', at least net-analyzer/tcpreplay has entire autogen in RDEPEND only for libopts bug #252940 I guess there are other packages in tree and overlays using bundled libopts, but nobody noticed yet. Searching '"dep: libopts25" site:packages.debian.org' also found: https://packages.debian.org/sid/ntp So we already have 3 packages. P.S. I think this bug should block bug #535782 , not duplicate it.
When resolved, attend gnutls libopts usage.
my reading of the autogen build is that libopts is not trivial to separate out. you can do a full build of autogen and then get a standalone tarball for libopts, but the bootstrap aspect there is unpleasant. it's also not clear to me that autogen supports building against an external/system copy of libopts. let's see if Bruce (upstream) has guidance/thoughts for us.
I have no idea why net-libs/gnutls would "RDEPEND" on sys-devel/autogen. The construction of the source tarball certainly does, but once you have that tarball, neither autogen nor even libopts is needed. The source tarball contains (should contain) the libopts source code. gnutls build ought to include something like: > rm -rf libopts libopts-* > gunzip -c $(autoopts-config libsrc) | \ > tar -xvf - > mv libopts-*.*.* libopts to put that library into its buildable source. > Alternatively, this tiny library could simply be patched into gnutls > for the tiny functionality it actually provides. Perhaps I'm mistaken. I thought it was. That is what NTP does, for certain. I can't get to the GNU Savannah archive, but here is a link to the README that gets rolled into the "tear-off" library: https://sourceforge.net/p/autogen/code/ci/master/tree/pkg/libopts/README It goes into painful detail as to how to incorporate the source. If there is anything missing or unclear, please let me know.
(In reply to Bruce Korb from comment #16) we explicitly delete libopts from gnutls and force it to use the system copy. that is why it RDEPENDs on autogen. we (and pretty much every distro out there) don't want packages bundling copies of the same library over and over. if there's bugs we need to fix, we want to fix/deploy it once, not try and track down every random package that bundles it. so to that end, we would like a release/method to build+install just libopts.
No news here.
