From: Luis Chamberlain <mcgrof@kernel.org>
To: Ole Schuerks <ole0811sch@gmail.com>
Cc: deltaone@debian.org, jan.sollmann@rub.de, jude.gyimah@rub.de,
linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org,
masahiroy@kernel.org, thorsten.berger@rub.de
Subject: Re: [PATCH v4 02/12] kconfig: Add picosat.c (1/3)
Date: Thu, 5 Sep 2024 01:55:37 -0700 [thread overview]
Message-ID: <ZtlyCR4EloWbeWG7@bombadil.infradead.org> (raw)
In-Reply-To: <20240829212352.38083-1-ole0811sch@gmail.com>
On Thu, Aug 29, 2024 at 11:23:52PM +0200, Ole Schuerks wrote:
> If one has to install some external package first,
> then that might diminish the usefulness. While there are extreme cases
> where it can take hours to manually identify all the dependencies, first
> having to build PicoSAT might take longer than manually resolving the
> conflict. Many users might then never install PicoSAT to try out the
> conflict resolver, even if they would benefit from it.
That's a package dependency problem, ie, a distro thing to consider
which packages users should have installed. But isn't the bigger issue
the fact that you want some C library not the picosat binary tool? Or
would it suffice to just have picosat as a binary installed? I see at
least debian has python3 bindings now too python3-pycosat. So what type
of picosat integration really is best for the task at hand?
> So the question is whether using PicoSAT as an external library is worth
> the portability issues and effort, and whether it wouldn't make more sense
> to directly include the PicoSAT source file.
The pros of an external library are less burden on maintenance, and
otherwise we'd be forking PicoSAT, but as I mentioned, I don't see a c
library but instead just the picosat binary. An alternative is to use PicoSAT as
a git subtree inside Linux on a dedicated directory, this way PicoSAT
can evolve and we can update it when we need to. Note a git subtree is
not the same thing as a git submodule, those are terrible.
> Otherwise, if we go with not including the PicoSAT source, then one could
> inform users about the missing package in the GUI, like this:
> When PicoSAT is installed:
> https://drive.google.com/file/d/1asBfLp1qfOq94a69ZLz2bf3VsUv4IYwL/view?usp=sharing
> When PicoSAT is not installed:
> https://drive.google.com/file/d/1ytUppyFPtH_G8Gr22X0JAf5wIne-FiJD/view?usp=sharing
>
> Let us know what you think. Include PicoSAT directly as a source or not,
> and then inform the user via the GUI?
Do you need the picosat binary or the actual c code for helpers /
library? I don't think we have anything in Linux yet using git
subtrees, but I don't see why we wouldn't for generic tooling and
this might be a good example use case.
Luis
next prev parent reply other threads:[~2024-09-05 8:55 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-10 6:52 [PATCH v4 00/12] kconfig: Add support for conflict resolution Ole Schuerks
2024-07-10 6:52 ` [PATCH v4 01/12] kconfig: Add picosat.h Ole Schuerks
2024-07-10 6:52 ` [PATCH v4 02/12] kconfig: Add picosat.c (1/3) Ole Schuerks
2024-08-12 8:41 ` Masahiro Yamada
2024-08-16 10:20 ` Ole Schuerks
2024-08-19 22:04 ` Luis Chamberlain
2024-08-29 21:23 ` Ole Schuerks
2024-09-05 8:55 ` Luis Chamberlain [this message]
2024-09-20 9:07 ` Ole Schuerks
2024-07-10 6:52 ` [PATCH v4 03/12] kconfig: Add picosat.c (2/3) Ole Schuerks
2024-07-10 6:52 ` [PATCH v4 04/12] kconfig: Add picosat.c (3/3) Ole Schuerks
2024-07-10 6:52 ` [PATCH v4 05/12] kconfig: Add definitions Ole Schuerks
2024-07-10 6:52 ` [PATCH v4 06/12] kconfig: Add files for building constraints Ole Schuerks
2024-08-12 8:49 ` Masahiro Yamada
2024-08-12 10:00 ` Masahiro Yamada
2024-07-10 6:52 ` [PATCH v4 07/12] kconfig: Add files for handling expressions Ole Schuerks
2024-08-12 8:46 ` Masahiro Yamada
2024-08-16 10:23 ` Ole Schuerks
2024-07-10 6:52 ` [PATCH v4 08/12] kconfig: Add files for RangeFix Ole Schuerks
2024-07-10 6:52 ` [PATCH v4 09/12] kconfig: Add files with utility functions Ole Schuerks
2024-08-12 8:48 ` Masahiro Yamada
2024-07-10 6:52 ` [PATCH v4 10/12] kconfig: Add tools Ole Schuerks
2024-07-10 6:52 ` [PATCH v4 11/12] kconfig: Add xconfig-modifications Ole Schuerks
2024-08-12 9:28 ` Masahiro Yamada
2024-07-10 6:52 ` [PATCH v4 12/12] kconfig: Add loader.gif Ole Schuerks
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZtlyCR4EloWbeWG7@bombadil.infradead.org \
--to=mcgrof@kernel.org \
--cc=deltaone@debian.org \
--cc=jan.sollmann@rub.de \
--cc=jude.gyimah@rub.de \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=masahiroy@kernel.org \
--cc=ole0811sch@gmail.com \
--cc=thorsten.berger@rub.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox