Open D3vil0p3r opened 1 year ago
I'm sorry but nothing can be done here.
Installation of all the tools in the
blackarch
package group.
You shouldn't try to install all 2800+ tools at once. cf. https://github.com/BlackArch/blackarch-site/pull/152
Among the 2800+ tools there are some with incompatible dependencies that can't be installed at the same time. You hit one example.
The only solution: install only the tool you need.
@noraj By analyzing the error, it is caused by the following tools:
mariadb-libs
and libmariadbclient
are in conflict but I think it can be solved easily by editing the PKGBUILD
of the last three tools and replacing libmariadbclient
to mariadb-libs
.
This action has no impacts because when you install mariadb-libs
, it provides also libmariadbclient
(https://archlinux.org/packages/extra/x86_64/mariadb-libs/)
Furthermore, I noted that, if you run sudo pacman -S libmariadbclient
, you get:
resolving dependencies...
looking for conflicting packages...
Package (2) New Version Net Change
extra/liburing 2.3-1 0,23 MiB
extra/mariadb-libs 10.9.4-2 22,75 MiB
I understand that managing so many tools and their dependencies could be heavy, but at least on those conflicting deps that provide the same libraries with 0 impact, I think it could be worth to apply these changes.
The case above about mariadb is easier because libmariadbclient
installs mariadb-libs
itself.
I would like to put myself from the point of view of the user that for its personal reason would like to install the entire group of blackarch
.
If you agree, I can open a PR for replacing libmariadbclient
with mariadb-libs
. Or we can submit a hydra
PKGBUILD in BlackArch that refers to libmariadbclient
dep instead of mariadb-libs
.
Thanks.
I understand that managing so many tools and their dependencies could be heavy, but at least on those conflicting deps that provide the same libraries with 0 impact, I think it could be worth to apply these changes.
If there is no impact we could update those deps.
I would like to put myself from the point of view of the user that for its personal reason would like to install the entire group of
blackarch
.
There is no such use case in real life, most of the time they are user that don't know what to install so they want to install everything "just in case" but will use less than 1% of the tools. That's why we offered a Slim ISO version that install the most common tools https://github.com/BlackArch/blackarch-iso/blob/594be7aa4abce9ff2cf9a1abb3c7d1a1283dbdd7/slim-iso/packages.x86_64#L243. But if one really want to install (most) of the tools there is still the Full ISO. But in practice that won't be physically possible to install all BA tools and the same applies to AL. For mariadb you are able to replace a lbi by another one that is maybe most recent and that is compatible (does the same thing) but just for nodejs tools there are tool that works only with last node version, some only with nodejs-lts-fermium, some only with nodejs-lts-gallium and some only with nodejs-lts-hydrogen. But each major version is not retrocompatible with the previous ones and unlike electron they can't be installed side by side. Hopefully there are not many tools with those dependencies. This is just an example of unresolvable conflict but there are maybe more. Just to say that solving this mariadb conflict won't solve the pacman -S blackarch
conflict. This is why we removed this command from the documentation because it not recommended at all as it can't work properly. So people still doing that should have a good reason, know what you are doing and are willing to spend time troubleshooting. We, has unpaid volunteer open-source maintainer working on our free-time won't help people asking for help for something that is not supported and not recommended like that. So if you want to PR to solve some conflict you are very welcome to do so and we will be pleased but please don't open new issue about conflicts from pacman -S blackarch
.
Thank you for the clarification @noraj I will finish the tests and I will open related PRs if tests end successfully.
Just for completing the discussion, I agree about what you reported on blackarch
package group. Apart this, could be a little chance where a set of tools that people use could be affected by incompatibility or conflicts, just think if in my machine I have installed hydra and argus-clients only, regardless the usage of blackarch
group.
This is the reason why, whereas possible, I would try to solve conflicts.
Just for information, currently, about all tools, the conflicting packages seem to not be a lot, and they are the following:
#python-yara and python-yara-rednaga conflict
apkid
python-yara-rednaga
ssma
##depending on apkid
mobsf
quickscope
#mariadb-libs and libmariadb-client conflict
argus-clients
qt3
xplico
##depending on qt3
pyqt3
qscintilla-qt3
##depending on pyqt3
faradaysec
gerix-wifi-cracker
inguma
#mariadb-libs and libsqlclient conflict (due to 'mysql' package)
braces
facebrok
Some of these conflicts affect also BA subcategories (as blackarch-network or blackarch-mobile).
nodejs
and nodejs-lts-*
conflict:
$ grep -r nodejs-lts packages
packages/bloodhound/PKGBUILD:depends=('nodejs-lts-gallium' 'neo4j-community' 'alsa-lib' 'gtk3' 'libxss' 'nss'
packages/bagbak/PKGBUILD:depends=('nodejs-lts-gallium' 'zip')
$ grep -r "'nodejs'" packages
packages/box-js/PKGBUILD:depends=('nodejs' 'gnuplot')
packages/nodejs-electron-packager/PKGBUILD:depends=('nodejs')
packages/beef/PKGBUILD:depends=('ruby' 'ruby-bundler' 'sqlite' 'python2' 'libxslt' 'nodejs')
packages/cloudsploit/PKGBUILD:depends=('nodejs')
packages/wssip/PKGBUILD:depends=('nodejs' 'coffee-script')
packages/brosec/PKGBUILD:depends=('nodejs' 'xsel')
packages/snarf-mitm/PKGBUILD:depends=('nodejs')
packages/bluebox-ng/PKGBUILD:depends=('nodejs' 'coffee-script' 'python2' 'nmap')
packages/nodejs-colors/PKGBUILD:depends=('nodejs')
packages/retire/PKGBUILD:depends=('nodejs')
packages/sn1per/PKGBUILD: 'goohak' 'hydra' 'metasploit' 'nbtscan' 'nikto' 'nmap' 'php' 'nodejs'
packages/moloch/PKGBUILD: 'elasticsearch' 'geoip' 'libnids' 'nodejs')
packages/node-ar-drone/PKGBUILD:depends=('nodejs')
packages/expose/PKGBUILD:depends=('nodejs' 'clang' 'gnuplot' 'python2' 'mitmproxy' 'npm' 'libxtst')
packages/git-dump/PKGBUILD:depends=('nodejs' 'git')
packages/novahot/PKGBUILD:depends=('nodejs')
packages/h8mail/PKGBUILD: 'nodejs')
packages/xxexploiter/PKGBUILD:depends=('nodejs' 'npm')
packages/hellraiser/PKGBUILD: 'ruby-foreman' 'ruby-rake' 'nodejs')
packages/gsa/PKGBUILD:makedepends=('yarn' 'doxygen' 'xmltoman' 'nodejs' 'npm')
packages/leena/PKGBUILD:depends=('nodejs')
packages/uppwn/PKGBUILD:depends=('python2' 'python2-selenium' 'python2-xvfbwrapper' 'nodejs' 'phantomjs'
packages/pown/PKGBUILD:depends=('nodejs')
packages/express/PKGBUILD:depends=('nodejs')
packages/jstillery/PKGBUILD:depends=('nodejs')
packages/pwned/PKGBUILD:depends=('nodejs')
It is true what you say. I don't understand why my system installed both beef
and bloodhound
from BA repo without installing nodejs (and without warning messages) and I have only nodejs-lts-gallium
...
Well, I recently got a method that could not be truly called a "method", that if you install the kde-applications ahead of installing the blackarch package, there would be no warnings, and you can continue the installations. I wonder if there are something in the kde-applications that can replace the conflicted packages……
@D3vil0p3r Would you like to test the conflict resolution for mariadb-libs and libsqlclient, then PR is everyting goes well?
@D3vil0p3r Would you like to test the conflict resolution for mariadb-libs and libsqlclient, then PR is everyting goes well?
Time ago I PRed all tools... Are there other new or update packages containing libsqlclient?
@D3vil0p3r Would you like to test the conflict resolution for mariadb-libs and libsqlclient, then PR is everyting goes well?
Time ago I PRed all tools... Are there other new or update packages containing libsqlclient?
You're right, checking with grep -r libmysqlclient packages
, none is using it anymore. #3873 must be using an old ISO or not having updated for a long time.
So what's left? Could we close this issue?
I did an additional investigation and I don't see that dependency. If the user on https://github.com/BlackArch/blackarch/issues/3873 is getting that error, could it be that libmysqlclient
could be a subdependency of a dependency of a tool?
Let me try to install blackarch
group in a clean machine for checking if I get the same error...
Right, tehre only those two matches:
$ grep -r "'mysql'" packages
packages/braces/PKGBUILD:depends=('php' 'mysql')
packages/facebrok/PKGBUILD:depends=('php' 'mysql')
Created https://github.com/BlackArch/blackarch/pull/3874 and https://github.com/BlackArch/blackarch/pull/3875 for fixing them.
Bug description
Hello, I'm using a clean Arch Linux machine and I'm trying to install all the tools in the
blackarch
package group. When I execute:I get the following error:
How can I solve this issue?
Steps to reproduce
sudo pacman -Syyu
andsudo pacman -S blackarch
Actual result: Error message:
Expected result: Installation of all the tools in the
blackarch
package group.