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
signature.asc
Description: PGP signature
