From 5d346589ed4431a048aeece4840c75d4bac9d753 Mon Sep 17 00:00:00 2001 From: Franco Fichtner Date: Tue, 27 Aug 2024 08:57:45 +0200 Subject: [PATCH] plugins: add conflicts to #4202 In order to devise a plan to cope with plugins that deinstall other plugins the best approach seems to be to simply tell the core that other plugins are conflicting. We already have that information so we just have to pass it along. It's a bit similar to pkg and ports where this information is available during build but not used later during runtime. Conflicts are based on installing the same file, but pkg only notices this when it starts installing and will try to tell you again, but it could have already kown. Needs some glue in core as well but it will be very cool. --- Mk/defaults.mk | 1 + Templates/version | 1 + 2 files changed, 2 insertions(+) diff --git a/Mk/defaults.mk b/Mk/defaults.mk index f6c805c99..f6a290862 100644 --- a/Mk/defaults.mk +++ b/Mk/defaults.mk @@ -75,6 +75,7 @@ PLUGIN_PYTHON?= ${_PLUGIN_PYTHON:[2]:S/./ /g:[1..2]:tW:S/ //} REPLACEMENTS= PLUGIN_ABI \ PLUGIN_ARCH \ + PLUGIN_CONFLICTS \ PLUGIN_HASH \ PLUGIN_MAINTAINER \ PLUGIN_NAME \ diff --git a/Templates/version b/Templates/version index 6d97cfccb..82d753f28 100644 --- a/Templates/version +++ b/Templates/version @@ -1,6 +1,7 @@ { "product_abi": "%%PLUGIN_ABI%%", "product_arch": "%%PLUGIN_ARCH%%", + "product_conflicts": "%%PLUGIN_CONFLICTS%%", "product_email": "%%PLUGIN_MAINTAINER%%", "product_hash": "%%PLUGIN_HASH%%", "product_id": "%%PLUGIN_PKGNAME%%",