Hi, When `dev-db/sqlite` is pulled it compiles lib and CLI (`sqlite`) too. It can be unnecessary to get the binary if one is interested in the libs only. The idea would be to introduce a new internal useflag, enabled by default, to compile the CLI. ``` cli: install the `sqlite` CLI ``` From a quick look in the sqlite codebase, `./configure` does not seem to allow skipping the CLI compilation. With `cli` deactivated, the ebuild will just remove the `sqlite` binary from the installed packages. Reproducible: Always
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.
