Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 498324 - sys-devel/autogen: split off libopts
Summary: sys-devel/autogen: split off libopts
Status: UNCONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal enhancement with 1 vote (vote)
Assignee: Gentoo Toolchain Maintainers
URL:
Whiteboard:
Keywords:
: 535782 (view as bug list)
Depends on:
Blocks: 499378 535782
  Show dependency tree
 
Reported: 2014-01-17 06:57 UTC by Arc Riley
Modified: 2023-09-03 20:33 UTC (History)
8 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Arc Riley 2014-01-17 06:57:15 UTC
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.
Comment 1 Arc Riley 2014-01-17 07:00:12 UTC
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.
Comment 2 Alon Bar-Lev (RETIRED) gentoo-dev 2015-01-11 22:59:54 UTC
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.
Comment 3 Luke-Jr 2015-01-11 23:08:49 UTC
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.
Comment 4 Alon Bar-Lev (RETIRED) gentoo-dev 2015-01-11 23:12:23 UTC
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.
Comment 5 Luke-Jr 2015-01-12 01:13:56 UTC
(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.
Comment 6 Jeroen Roovers (RETIRED) gentoo-dev 2015-02-14 08:34:40 UTC
*** Bug 540038 has been marked as a duplicate of this bug. ***
Comment 7 Cedric Sodhi 2015-02-14 08:42:07 UTC
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.
Comment 8 Alon Bar-Lev (RETIRED) gentoo-dev 2015-02-14 09:03:46 UTC
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.
Comment 9 Cedric Sodhi 2015-02-14 09:10:06 UTC
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.
Comment 10 Alon Bar-Lev (RETIRED) gentoo-dev 2015-02-14 09:16:46 UTC
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.
Comment 11 Alon Bar-Lev (RETIRED) gentoo-dev 2015-02-24 15:02:47 UTC
*** Bug 535782 has been marked as a duplicate of this bug. ***
Comment 12 Nikoli 2015-02-24 15:21:47 UTC
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.
Comment 13 Alon Bar-Lev (RETIRED) gentoo-dev 2015-08-19 08:59:05 UTC
When resolved, attend gnutls libopts usage.
Comment 14 Alon Bar-Lev (RETIRED) gentoo-dev 2015-08-19 08:59:42 UTC
*** Bug 535782 has been marked as a duplicate of this bug. ***
Comment 15 SpanKY gentoo-dev 2016-02-18 21:17:53 UTC
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.
Comment 16 Bruce Korb 2016-02-19 00:27:27 UTC
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.
Comment 17 SpanKY gentoo-dev 2016-02-19 02:03:13 UTC
(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.
Comment 18 Andreas K. Hüttel archtester gentoo-dev 2023-09-03 20:33:49 UTC
No news here.