On 2022-10-12 11:29:52 (+1000), Allan McRae wrote:
On 11/10/22 21:00, Levente Polyak wrote:
On 10/11/22 12:05, David Runge wrote:
- preserve base-devel as a group there
makedepends doesn't actually matter, similar how checkdepends doesn't matter. Our builders always have the full repository set available (minus multilib). We only need to consider runtime depends.
I would argue that makedepends and checkdepends do matter from a testing perspective. If we have [core] defined at essential packages to bootstrap a system, build time dependencies remain important and should go through testing.
Of course that depends on our definition of [core]... I like the above definition, as it reflects the history of our distro starting from Linux From Scratch, and the build dependencies for things in [core] are fairly fundamental to things outside core too (e.g. meson) and deserve enforced [testing].
It also serves us well as more architectures happen - that would make [core] a self contained start point for bootstrapping an architecture.
If we look at it from a bootstrap perspective, then it would indeed be good to become self-contained in regards to makedepends and maybe also checkdepends (more overhead though). I agree, that this should encompass build tools used for the packages in core (such as meson) in the future in regards to "going through testing", but I would not want all the build tools in there (e.g. cmake, waf, scons, whathaveyou), if they are not required by packages in [core]. This breaks with the above base-devel assumption in case we ever want to add all the build tools to it. However adding build tools in general also drags in its own kitchen sink, and I understand why the rather small group of developers might not be fond of this.
In summary, we need to define what it is we are trying to achieve with [core].
Hm, we could create an RFC for evaluating and defining this better. It seems, that people have very different ideas and opinions about what should be in core and what not :) Maybe this would also provide a better overview to what proposed changes would actually mean in terms of added packages etc. Best, David -- https://sleepmap.de