Hi,
When the size of the repo is considered too big maybe we can revisit the option
of having the portage tree distributed as a compressed sqashfs image.
$ du -hs /var/db/repos/gentoo
536M .
$ gensquashfs -k -q -b 1M -D /var/db/repos/gentoo -c zstd -X level=22
/tmp/gentoo-current.zstd.sqfs
$ du -h /tmp/gentoo-current.zstd.sqfs
47M /tmp/gentoo-current.zstd.sqfs
Though that would probably open another can of worms around incremental updates
to the portage tree, or more precisely the lack of it (i.e. increased bandwidth
requirements).
Regardless, as a proxied maintainer I agree with Flow's point of view here (I
think I have expressed these in detail too in the past here) and would prefer
undeprecating EGO_SUM.
Zoltan
On Fri, Sep 30, 2022 at 05:10:10PM +0200, Jaco Kroon wrote:
> 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
>
