Trim the Beard

This page is a place for us to put our ideas and thoughts related to 'trimming the beard'.

The concept here is for Funtoo 2.0, to reduce the number of ebuilds that are part of the distro, thus reducing the maintenance burden, and focusing more on the packages we care about and need. There are currently about 20,000 packages in Gentoo. This is not really maintainable or sustainable.

Brainstorm

It is fine to add a paragraph(s) here with your ideas on this effort.

World Files

A good place to start is to look at our world files. Funtoo exists for its users not just to maintain thousands of packages. We should maintain packages that are important to us. The worldfile on my (Daniel's) current desktop includes:

   

app-admin/metalog
app-admin/sudo
app-editors/vim
app-editors/vscode-bin
app-emulation/vagrant
app-emulation/virtualbox-bin
dev-db/mongodb
dev-lang/python
dev-lang/python:2.7
dev-python/coverage
dev-python/entrypoints
dev-python/geopy
dev-python/pymongo
dev-python/pytest
dev-python/pyzmq
dev-python/virtualenv
dev-util/pycharm-professional
gnome-base/gnome
media-video/obs-studio
net-im/discord-bin
net-im/slack-bin
net-im/telegram-desktop-bin
net-im/zoom-bin
net-misc/ntp
net-vpn/networkmanager-openvpn
net-vpn/openvpn
sys-apps/iucode_tool
sys-apps/metatools
sys-auth/nss-mdns
sys-boot/grub
sys-firmware/intel-microcode
sys-fs/zfs
sys-kernel/debian-sources-lts
sys-kernel/linux-firmware
sys-process/htop
www-client/firefox
www-client/google-chrome
x11-drivers/nvidia-kernel-modules

Weighted Results

If we aggregate world files, do we weight the importance of a given package by the frequency of occurrence? Or do we just want a pure set: a package is equally important if 1 or 100 people have it in their world files?

Autogen determine packages

I can write smal script to work that :

• Get list gentoo packages with count ebuild
• In first get packages where count > 3
• If package from above field not have autobuild should will be add to list

Above list give us more maintained packages

Autogen secure stable packages

I know i am monotony. And i know @drobins You worked on this. But for my perspective is very importand

Support for AppImage/Flatpak/etc

Sometimes, upstream projects package applications, and nowadays many of them do a "good enough" job. The consequence is that Funtoo can rely more on application developers to create packages. (We are already doing this with firefox-bin, google-chrome, zoom-bin, etc.)

The three most common formats seem to be AppImage, Flatpak, and Snap. AppImage works out of the box (because an AppImage package is an executable wrapper around an ISO 9660 fs), but desktop integration is a bit of a hassle. appimaged is a good start, but it is not complete. Maybe some ebuild and metatools magic could help. I personally have LibreOffice and Krita running via AppImages installed to /usr/local/bin.

Some Funtoo'ers have installed Flatpak from an official Flatpak overlay with a little bit of tweaking. Flatpak is supposed to integrate well with the GNOME desktop (and probably others). I personally have yet to try Flatpak.

Then there are a few projects that still use more traditional methods that ultimately involve writing to a self-contained directory on the filesystem: tarballs extracted to /opt, git repos, etc: texlive, plan9port, Pale Moon, upstream Mozilla Firefox/Thunderbird tarballs. Some of these are already transformed into native packages with ebuild and metatools magic. Some more of them can be.

Advantages of utilizing upstream pre-compiled packaging:

• Less work for Funtoo developers.
• Installations of applications can be officially condoned by upstream app developers.
• Many useful one-off utilities could be easily installed (see Flatpak hub) and updated without bothering Funtoo developers to package them.

Disadvantages:

• Processor optimizations (e.g. avx, avx2) are not used.

Flatpak:

https://bugs.funtoo.org/browse/FL-6770 Should be ported

Autogen Support

Is is possible to generate template files for such ebuilds programmatically?

Using a BINHOST

If we want to make things easier in the sense of providing users a package without making them compile it fully, we could provide our own binaries, Sabayon style, but maintaining as much subarch and profile optimization as possible. That's a lot of USE flag combos, but by whittling the package count down (and other build optimization, e.g. optimal cacheing), we could provide binaries for a wide variety of subarches with a reasonable amount of expensive cpu work and electricity.

Optimizing Dependency Graph Analysis

One of the things that I liked about equo on Sabayon was it's (much quicker) dependency calculations, especially on slow hardware. Can trimming the beard help speed this up in Portage? This would help greatly for updating SBCs automatically.