Hi, On 2022/09/30 16:53, Florian Schmaus wrote: > jkroon@plastiekpoot ~ $ du -sh /var/db/repos/gentoo/ >> 644M /var/db/repos/gentoo/ >> >> I'm not against exploding this by another 200 or even 300 MB personally, >> but I do agree that pointless bloat is bad, and ideally we want to >> shrink the size requirements of the portage tree rather than enlarge. > > What is the problem if it is 400 MB more? ? What if we double the > size? Would something break for you? Does that mean we should not add > more packages to ::gentoo? Where do you draw the line? Would you > rather have interested persons contribute to Gentoo or drive them away > due the struggle that the EGO_SUM deprecation causes? How long is a piece of string?
I agree with you entirely. But if the tree gets to 10GB? At some point it may be worthwhile to split the tree similar to what Debian does (or did, haven't checked in a while) where there is a core, non-core repo etc ... except I suspect it may be better to split into classes of packages, eg, x11 (aka desktop) style packages etc, and keep ::gentoo primarily to system stuff (which is also getting harder and harder to define). And this also makes it harder for maintainers. And this is really already what separate overlays does except the don't (as far as I know) have the rigorous QA that ::gentoo has. But again - at what point do you do this - and this also adds extra burden on maintainers and developers alike. And of course I could set a filter to not even --sync say /x11-* at all. For example. Or /dev-go or /dev-php etc ... So perhaps you're right, this is a moot discussion. Perhaps we should just say let's solve the problem when (if?) people complain the tree is too big. No, I'm not being sarcastic, just blunt (; The majority of Gentoo users (in my experience) are probably of the developer oriented mindset either way, or have very specific itches that need scratching that's hard to scratch with other distributions. Let's face it, Gentoo to begin with should probably not be considered an "easy" distribution. But it is a highly flexible, pro-choice, extremely customizable, rolling release distribution. Which scratches my itch. Incidentally, the only categories currently to individually exceed 10MB are these: 11M media-libs 11M net-misc 12M dev-util 13M dev-ruby 16M dev-libs 30M dev-perl 31M dev-python And by far the biggest consumer of space: 124M metadata Kind Regards, Jaco
