Summary: | dev-db/sqlite-3.37.2: new useflag to get libs only | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Mathieu Tortuyaux <mathieu.tortuyaux> |
Component: | Current packages | Assignee: | Jakov Smolić <jsmolic> |
Status: | RESOLVED INVALID | ||
Severity: | enhancement | CC: | base-system, jstein |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Mathieu Tortuyaux
2022-02-16 11:43:27 UTC
This would mean that we have to go through all sqlite revdeps and verify whether they're using the binary and set `[cli(+)]` for all of them. If you don't want to install the cli I'd suggest to use INSTALL_MASK. Thanks for your answer. Maybe `cli` is not a correct name: `lib-only` would be more appropriate. This `lib-only` flag would be disabled by default, so we do not need to go through revdeps since the current behavior will remain the same. (In reply to mathieu.tortuyaux from comment #2) > Thanks for your answer. > > Maybe `cli` is not a correct name: `lib-only` would be more appropriate. > This `lib-only` flag would be disabled by default, so we do not need to go > through revdeps since the current behavior will remain the same. A package might be relying on the presence of the cli binary in sqlite without us knowing, so it would be broken if a user installs it and sqlite without the cli. Removing the sqlite binary changes the package more than e.g. adding support for an optional configure flag. Furthermore, there is no such configure option that enables us to build only library, so we would have to "hack" our way to installing only library. (In reply to Jakov Smolić from comment #3) > (In reply to mathieu.tortuyaux from comment #2) > > Thanks for your answer. > > > > Maybe `cli` is not a correct name: `lib-only` would be more appropriate. > > This `lib-only` flag would be disabled by default, so we do not need to go > > through revdeps since the current behavior will remain the same. > > A package might be relying on the presence of the cli binary in sqlite > without us knowing, so it would be broken if a user installs it and sqlite > without the cli. Removing the sqlite binary changes the package more than > e.g. adding support for an optional configure flag. Furthermore, there is no > such configure option that enables us to build only library, so we would > have to "hack" our way to installing only library. Right, so we'd have a USE flag which just drops a file in src_install, which is usually considered a waste of a rebuild for people changing. Is INSTALL_MASK suitable for you, Mathieu? I think it should work for your case but let us know if it doesn't. (In reply to Sam James from comment #4) > (In reply to Jakov Smolić from comment #3) > > (In reply to mathieu.tortuyaux from comment #2) > > > Thanks for your answer. > > > > > > Maybe `cli` is not a correct name: `lib-only` would be more appropriate. > > > This `lib-only` flag would be disabled by default, so we do not need to go > > > through revdeps since the current behavior will remain the same. > > > > A package might be relying on the presence of the cli binary in sqlite > > without us knowing, so it would be broken if a user installs it and sqlite > > without the cli. Removing the sqlite binary changes the package more than > > e.g. adding support for an optional configure flag. Furthermore, there is no > > such configure option that enables us to build only library, so we would > > have to "hack" our way to installing only library. > > Right, so we'd have a USE flag which just drops a file in src_install, which > is usually considered a waste of a rebuild for people changing. > > Is INSTALL_MASK suitable for you, Mathieu? I think it should work for your > case but let us know if it doesn't. I'll go with `INSTALL_MASK`, it works as expected. :) The idea behind was to control from the ebuild itself what it's actually installed. Thanks for your answers anyway, it was really appreciated. Let's close this issue then. |