Etckeeper package dependencies

Can anyone let me know why the SuSE package for etckeeper wants to install bzr and subversion?
I’d much rather have it be the minimal install (only git+python dependencies) as the original package was set to do.
With all those dependencies, it starts to make more sense to install it from source.

Hi and welcome to the Forum :slight_smile:
You would need to ask the maintainers, seems it requires bzr…

https://build.opensuse.org/package/view_file/devel:tools:scm/etckeeper/etckeeper.spec?expand=1


# added for bzr 2014-07-10 bkbin005@rinku.zaq.ne.jp
BuildRequires:  bzr

Maybe it needs to change to a Recommends…

It only BuildRequires bzr (i.e. you need bzr for building it), but the binary package does not require it AFAICS.
https://build.opensuse.org/package/binary/devel:tools:scm/etckeeper?arch=x86_64&filename=etckeeper-1.18.5-11.3.x86_64.rpm&repository=openSUSE_Leap_42.2

Maybe something recommends bzr and subversion somewhere along the dependency chain?
Try installing it with “–no-recommends”:

sudo zypper in --no-recommends etckeeper

Or deselect bzr and subversion in YaST after you marked etckeeper for installation.

Doesn’t look like it.



# rpm -q bzr subversion
package bzr is not installed
package subversion is not installed

# zypper in -yd etckeeper-zypp-plugin etckeeper-cron 
Repository-Daten werden geladen...
Installierte Pakete werden gelesen...
Paketabhängigkeiten werden aufgelöst...

The following 3 NEW packages are going to be installed:
  etckeeper etckeeper-cron etckeeper-zypp-plugin

The following application is going to be REMOVED:
  GChemPaint

The following 2 recommended packages were automatically selected:
  etckeeper-cron etckeeper-zypp-plugin

3 new packages to install.

So actually, I have no idea what the OP is talking about.

However, there is one thing that looks a little strange about this package, as IMHO at least the “cron” and the “zypp-plugin” sub packages should clearly be packaged as “noarch”.

In addition, the main package does not contain any architecture specific binaries or shared objects and it looks the only reason to “make” it an architecture specific package is this here.


PYTHON_INSTALL_OPTS="--prefix=%{_prefix} --install-purelib=%{python_**sitearch**}" \

If you replace that with


PYTHON_INSTALL_OPTS="--prefix=%{_prefix} --install-purelib=%{python_**sitelib**}" \

and make the respective changes to the %files section, the package builds fine as “noarch” without any complaints by rpmlint of architecture dependent code.

AK