With native 64-bit software becoming more available, and many individuals not requiring 32-bit computability libraries, it would be great to also provide -nomultilib stages for installation. While the autobuilds are an excellent improvement, it's a bit tedious to have to recompile alot of system components (especially gcc + glibc) when one changes to the nomultilib profile during installation. Reproducible: Always
The amd64 autobuild is already taking over 24 hours since the hardened multilib and nomultilib stages have been added. I'd rather not add anything else to it.
Wow, that makes sense. Though, I can't believe there is a bigger desire to have hardened no-multilib than standard no-multilib :\
Actually, I had another idea regarding this. What about alternate builds? So, alternate between building standard, and hardened stages, on an every-other basis? So, if its set to build on, say January 1st, and January 5th, have the 1st build stages for standard profiles (default, and no-multilib), and the hardeneed (default, no-multilib) on the 5th, and continually alternate? This might help reduce the build time and overhead and provide more variety, and the cost of having the sets be another week or so out of date. Just a thought - thanks again!
(In reply to comment #2) > Wow, that makes sense. Though, I can't believe there is a bigger desire to > have hardened no-multilib than standard no-multilib :\ They asked first. Feel free to build your own stages instead of whining
Alternating the type of stages built would just serve to confuse users.
OK, I feel your comment relating to "whining" was pretty inappropriate. I wasn't saying alternating the offerings, just alternating which builds on which date. So, on 1 date, both hardened stages get built, and on the next, both standard get built; they could still remain separated on the mirror. The result is that one will lag 1 build-date behind the other, but the result would be offering both, and only having to build 2 at a time, instead of 3.
And the problem I mentioned still remains. Users will be confused if they go to particular date under amd64/ and there's only hardened stages.
I don't see why; the hardened stages would go to hardened/ still, and the standard would stay where they are. The only difference would be the build dates; for example, taking the last two builds as an example. Lets say 20090611 was the standard's round to build, and 20090618 was the hardened's build: 20090618 mirror://20090618/stage3-amd64-20090611.tar.bz2 mirror://20090618/stage3-amd64-nomultilib-20090611.tar.bz2 mirror://20090618/hardened/stage3-amd64-hardened+nomultilib-20090618.tar.bz2 mirror://20090618/hardened/stage3-amd64-hardened-20090618.tar.bz2 So, the next build will update the regular builds, leaving the hardened at 20090618.
The real concern here was adding more and more to the autobuild, which previously would fail if one part failed. Over the weekend, I added "build set" support to the catalyst-auto script. For amd64, it treats "multilib" (and installcd), hardened-multilib, and hardened-nomultilib as discreet build sets and moves on to the next one if something fails in the previous one. With this feature in place, I don't mind adding the nomultilib stages. However, I'm busy/lazy, and I'm not doing it right now.
Thanks alot for your help; again, I apologize if anything I mentioned came off negatively. I look forward to being able to install a pure64 stage without recompiling some toolchain items!
17:53 <+CIA-100> jmbsvicetto * r800 /trunk/releases/weekly/specs/amd64/ (3 files): Add nomultilib stages for amd64 - bug 273082. Now I just need to update the config files and add a cron job. I plan to start building these on my own server. If there's interest for them, I'll see about building them on the official box.
I've completed the first build run for nomultilib stages[1]. [1] - http://www.jmbsvicetto.name/releases/stage3-amd64-nomultilib-20110828.tar.bz2
This has been working for me for many months. I'm going to leave the bug open until I enable the build of the nomultilib target in the new releng box.
I've finally commited this change to the releng repo[1] [1] - http://git.overlays.gentoo.org/gitweb/?p=proj/releng.git;a=commitdiff;h=1c1dd9bf9e34063f7ea8abb0ed22059eb302f8a0
They are now being built and pushed to mirrors on the official Gentoo build box.
