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.
It is fine to add a paragraph(s) here with your ideas on this effort.
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
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.
- Processor optimizations (e.g. avx, avx2) are not used.
https://bugs.funtoo.org/browse/FL-6770 Should be ported
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.