Hi,
i think it is good time to start a discussion about ideas where cooker
development should get toward to.
Indeed -- we already did a bit of that in the last IRC meeting and decided to make a 4.1 release rather quickly (must-haves: fix issues found with 4.0, Qt 5.13, Plasma 5.16.x, kapps 19.08), so if we have anything HUGE, we may want to hold off on it until after 4.1 -- but right now at least I don't see anything in the core system that would require a major overhaul.
1. split-usr
I don't have a strong opinion on this either way -- the rationale given by proponents of merged-usr essentially comes down to "some stuff is broken, we don't want to fix it, so let's hide the issues".
The primary rationale given by opponents of it is also pretty weak and pretty much comes down to "let's not break the old concept so going back to it will be a lot harder if the stuff currently breaking it ever gets fixed".
With initrds/initramfs being what it is these days, the minimal rescue system that used to be in /bin, /sbin and friends has essentially moved to the initrd - so not really a lot of things lost by getting rid of that.
2. Disable debuginfo generation
While I agree that debuginfo packages aren't as useful as they could be (would be nice if the kde crash dialog could automatically download them and generate a more useful backtrace, for example), I don't think they're entirely useless, and outside of build time generating them doesn't have any drawbacks. While our infrastructure can deal with it, I don't see much of a reason to disable it.
3. Use BFD
4. Use LD.lld
Agreed about both of those -- gold was a nice try (and bfd still hasn't caught up with some things like ICF), but lately it hasn't been maintained and is more trouble than it's worth.
I'm leaning towards trying to use lld for everything (faster and can keep ICF) with exceptions for where it breaks, but haven't gotten around to checking how well lld works these days. I'll definitely run some checks when 9.0 is in the tree (lld is making progress fast).
5. Toybox
Toybox works really well and would certainly be a good replacement inside initramfs at least -- not sure if we want to do it in the whole system though (keep in mind that people [and Makefiles] will run scripts written on other distributions, and that hardcode flags to coreutils tools). Even switching to libarchive tar wasn't as 100% painless as it ought to be.
Also, toybox can replace more than just coreutils - awk, grep, sed, find, kmod, procps, psmisc, which, util-linux and a few more are all in there.
I'm not sure how complete those tools are and whether or not we could end up replacing some of those as well. The fewer tools are replaced, the less likely it is to have any benefit...
6. SecureBoot EFI
That would certainly be useful if it can be done in a way that doesn't complicate things too much for a normal user...
7. Get rid of GCC
Try to start a reserch how GCC can be stripped out of builds with
LLVM/clang
One big issue there is libstdc++ -- while clang has libc++ (which is actually better in many ways), if we care about binary compatibility with other distributions, we can't use it because otherwise we'd run into situations where e.g. a binary-only game built on some other distro links to Qt and libstdc++ (that would crash instantly on trying to runtime link to Qt built with libc++).
clang also uses the gcc command line tool to locate headers for intrinsics (/usr/lib64/gcc/x86_64-openmandriva-linux-gnu/9.1.0/include etc.) - that could probably be changed.
and use compiler-rt by default
We tried that before -- while it worked great for most stuff, we ran into binary compatibility problems in some weird situations (e.g. firefox built with compiler-rt crashing when loading the Flash plugin because of clashes with statically linked libgcc bits in there).
Fortunately almost nothing cares about Flash anymore, but that sort of BS is something we still need to look out for.
Probably it's safe to build most applications with compiler-rt -- but there's some potential for it getting messy as soon as something starts dlopening stuff built with something else. For normal libraries, fortunately it's easy to test (e.g. see if a Qt application built with libgcc will keep running if Qt is linked with compiler-rt).
Just swapping out Qt should give us a good impression, given that will also show us if plasma can still load plugins built with libgcc.
8. PGO
Type a list of packages that may benefit form PGO (i.e firefox, webkit,
kernel Kernel PGO)
Certainly worth looking into - probably mesa and qtwebengine would be good candidates too, but getting decent PGO data on them is hard given their use can vary greatly between applications
9. Reduce kernel size
Try to start a research on reducing kernel size, maybe disable some modules
which are not needed etc.
Absolutely, I've been meaning to split some modules people typically don't need into separate packages for some time, just never got around to do that (better to just split them into a separate package than to disable them altogether -- e.g. a typical desktop user will never need infiniband, but as soon as you start installing on servers, things may look different).
10. AutoFDO/BOLT
Try to start research on post-link optimizations
http://perl11.org/blog/bolt.html
Good idea.
11. Bye to 32-bit
This was already decided about in the last meeting -- essentially the outcome was that we should build stuff for a while longer, but start phasing it out (no more stable releases, but keep cooker/rolling so all libraries get built and wine, steam and other legacy cruft is guaranteed to find everything they need).
12. IWD
Use IWD as a modern alternative for wpa_supplicant for WiFi connections
Definitely time to start looking at it, but it doesn't seem to be ready for a load of WiFi drivers yet. Unless things improve quickly, we may need to have IWD for devices where it's known to work and keep wpa_supplicant for the others.
1. Fix "Create Build Lists of dependent projects"
+1
2. EVRD check
+1
3. Integrate QA (voting for a release of package) tool into ABF
+1
*Other*:
1. Use github issues as bug tracker
AFAIK QA people prefer bugzilla (and there's the issue of github being owned by M$ -- so far they've done well, but can we trust them forever?) - but now is the right time to look at possible options again...
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.
+1, I wonder if we can somehow merge this into the QA tool...
PR (or something like it) to non-cooker branch --> triggers build to see if it compiles, notifies QA and RM, starts voting process
Here's a few more things I've been thinking of -- not necessarily for 4.1:
Cooker:
- Early move to LLVM/Clang 9 -- there's finally patches adding RISC-V hardfloat support, and LLD has made a lot of progress
- Reduce the duplication of binutils tools (binutils, elfutils, llvm). Chances are the LLVM tools are good enough to handle debuginfo generation these days (main reason for elfutils to be in the default build environment right now)
- Check if using Polly can speed up some libraries -- it should be possible to at least somewhat parallelize libjpeg and friends (but the tools for doing that automatically may not be up to the task yet)
- Plasma customization tool in OM Welcome that allows people to quickly get to something they feel at home in, e.g. "Act like [*] OpenMandriva Windows MacOS" (where OpenMandriva is what we think is best, Windows does things like double-clicks, MacOS does stuff like global menu bar on top of screen)
- Allow running Android apps (I have Anbox sort of working, but we can do better than the Brokenbuntu crowd...)
- Add OnlyOffice as an alternative to LO (this is a bit painful because they use a load of nonstandard tools, including some prehistoric stuff)
- Text mode/server installer
- Finish the work on the Java stack at least to the point where maven/xmvn work properly again
- Fix the conflict between wine32 and wine64
- An experimental build that does what could be done if we didn't care about binary compatibility (glibc -> musl, libstdc++ -> libc++, libgcc -> compiler-rt) that doesn't replace the existing OS, but would be rather interesting to benchmark -- if only to see how much binary compatibility is costing us.
- Possibly replace firewalld with ufw (because the latter has a proper plasma interface). (Build the [fire]wall! Make Linux great again!)
And probably the most controversial one:
- Change the filesystem layout for multilib. Some distributions have started going for stuff like /usr/x86_64-linux-gnu/lib instead of /usr/lib64, /usr/i686-linux-gnu/lib instead of /usr/lib etc., and that's a really good idea because it allows installing compat libraries for more than just one 64bit and one 32bit architecture. This is useful especially now that qemu binfmt-misc stuff is working well and transparently launches stuff built for other architectures (think wine on ARM being able to run x86 Windows binaries because it has access to qemu and i686/x86_64 libraries). With the current lib64/lib FS layout, e.g. a user on aarch64 may want to install an x86_64 libjpeg to please whatever binary-only application and an i686 libjpeg to please wine -- but they can't go to /usr/lib64 (where aarch64 stuff lives) nor /usr/lib (where armv7hnl stuff lives).
We don't have to break compatibility with anything to do this -- /usr/lib64 and /usr/lib could be symlinks to the native 64 and 32 bit arches, so stuff hardcoding /usr/lib64 or /usr/lib would still find what it's looking for and install to the right place.
ABF:
- Better handling of errors that usually go away by trying again, such as "[MIRROR] kauth-5.59.0-1-omv4000.znver1.rpm: Interrupted by header callback: Server reports Content-Length: 148 but expected size is: 65492
[FAILED] kauth-5.59.0-1-omv4000.znver1.rpm: No more mirrors to try - All mirrors were already tried without success
Failed to set locale, defaulting to C
Error: Error downloading packages:
Cannot download kauth-5.59.0-1-omv4000.znver1.rpm: All mirrors were tried"
- Better handling of interrupted chain builds (e.g. when building KDE Frameworks and a build somewhere in the middle fails on one arch, allow resuming the chain build when the failed package is fixed)
- Easier way to publish a load of interdependent packages at the same time (e.g. build updated KDE Frameworks and rebuild Plasma against it, then publish all at the same time so people updating in between don't end up with a system that is part 5.58, part 5.59 and unlikely to work properly)
