On Tue, Jun 25, 2019 at 6:16 AM Tomasz Gajc <tpg...@gmail.com> wrote: > > Hi, > > i think it is good time to start a discussion about ideas where cooker > development should get toward to. > > Here are my ideas: > > Development: > > 1. split-usr > Currently our distro uses split-usr. Idea is to move /bin /sbin /lib into /usr > More information can be found here > https://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken/ >
This I definitely want to see. It's not a difficult change to implement, and doing so will bring us in line with all the other major distros (even Debian, which is now doing this by default in Debian 10!). > 2. Disable debuginfo generation > Use -g0 as a default compiler flag and disable debuginfo generation rpms > Each build there are tons of data generated in debuginfo packages which > nobody uses them. If aything bad happens, a segfaulting software may always > be rebuilded with debuginfo enabled. > Nope. I use them when things are breaking. We don't have a more user-friendly way to leverage them (like a retrace server), but they are useful. And if you can't produce debuginfo the first go around, you probably can't produce it when you need it. If we didn't have them, it would have been a lot harder for me to do quite a bit of the work I did during the omv4000 development cycle. > 3. Use BFD > By default LD.gold is used for linking shared objects. Looks like LD.gold is > not maintained at all in a couple of years. By default move to LD.bfd as it > is actievly maintained. > We should do this now, unless someone wants to step up and become an upstream developer of gold. :) > 4. Use LD.lld > Try to start a research on using LD.lld (lld is a new linker from LLVM suite) > maybe not globally, but for some important packages or these which current LD > does not handle well i.e. LibreOffice > I'm not a fan, but since we *are* already using Clang, it's probably worth looking into. > 5. Toybox > Try to start a research to use Toybox (http://landley.net/toybox/about.html) > as coreutils replacement > No. There are ways to build coreutils in a busybox/toybox style for those configurations that need it. Fedora does this today, and we could do it as well, now that we have the required RPM features. > 6. SecureBoot EFI > Try to start a research to adapt our ISO and boot loader to be SecureBoot > friendly. https://wiki.archlinux.org/index.php/Secure_Boot > This is not hard. I already prototyped this with an OMV livecd-tools build. Getting the pieces in place merely requires people being okay with the idea of us doing this work. > 7. Get rid of GCC > Try to start a reserch how GCC can be stripped out of builds with LLVM/clang > and use compiler-rt by default > Not a fan of getting rid of GCC or switching to compiler-rt. Not using it by default in any package is probably a good goal. Using compiler-rt will break ABI compatibility with everyone else, so we should not go there. > 8. PGO > Type a list of packages that may benefit form PGO (i.e firefox, webkit, > kernel http://coolypf.com/kpgo.htm) > Sure, why not? It's a fair bit of work to make PGO profiles, though... > 9. Reduce kernel size > Try to start a research on reducing kernel size, maybe disable some modules > which are not needed etc. > Or, you know, split the kernel package up so that extra modules are in a subpackage? That's what Fedora does so that kernel sizes can be reduced. Also, initramfs images should already only include modules being used since that's dracut's default behavior. > 10. AutoFDO/BOLT > Try to start research on post-link optimizations > http://perl11.org/blog/bolt.html > This is interesting... > 11. Bye to 32-bit > As evidenced by the Ubuntu kerfuffle, that's probably a bad idea. I'd like to see us reduce to Red Hat/Fedora style multilib repos in for x86_64 and aarch64 and not provide separate i686 and armv7hnl trees. > 12. IWD > Use IWD as a modern alternative for wpa_supplicant for WiFi connections > This should be an easy swap. NetworkManager will use it if it is available. > ABF: > > 1. Fix "Create Build Lists of dependent projects" > > 2. EVRD check > Extend repoclosure report to report differences in EVRD between x86_64 and > other arches and releases. Just to show only those rpm packages that have > older EVRD. > > 3. Integrate QA (voting for a release of package) tool into ABF > These ABF items seem good to me. > Other: > > 1. Use github issues as bug tracker > > 2. Enforce control for PR to other branches > Integrate "travis-like" tool into our github repo to allow merging changes > between branches. > Enforce PR approval process - i.e. Release Manager or QA accepts PR for other > branches. > I'm not a fan of our usage of GitHub. I'd love to see us self-host our source code using Pagure, which would give us the flexibility to integrate useful testing, gating, etc. for packages. PR approvals are probably not a good idea on the whole right now, our community isn't large enough to be able to support that model. -- 真実はいつも一つ！/ Always, there's only one truth! -- Cooker mailing-list https://www.openmandriva.org/lists
