On Thu, Jan 19, 2017 at 08:50:34PM +0100, Andreas Nilsson wrote: > On Thu, Jan 19, 2017 at 8:10 PM, Glen Barber <gjb_at_freebsd.org> wrote: > > I do want to weigh in here and inform I am actively watching this > > thread. clang(1) is not in disc1.iso or bootonly.iso because the > > MK_TOOLCHAIN knob is disabled in the targets that generate them. This > > has actually been the case for quite some time for these images. > > > > dvd1.iso does contain clang, but very rarely (if ever, actually) are > > there dvd1.iso images produced for development snapshots. This is, in > > part, solely because of the additional space/bandwidth required on the > > mirrors (not just mirrors controlled by the Project, but third-party > > mirrors as well). > > > > I am working on splitting out how the memstick.img and disc1.iso images > > are produced, but ran into a problem which I'm looking into a workaround > > that is backwards-compatible. Since for USB images, a 700MB limit does > > not make sense, and right now it just so happens that the memstick.img > > is created from the same contents of disc1.iso. > > > > I know this does not help with the immediate issue, but wanted to chime > > in with I do see and understand the larger issue, and am working on > > a more long-term resolution instead of a one-line workaround. > > > > > Good to see discussion, but my 5c is: do not enlarge regular install media, > it is hefty enough. I'd rather see it shrink, although without the > limitations of old cd's rescue-env. > > Install media is install media, not live image. Live usb-sticks are so easy > to do on your own, why waste the Projects storage and bandwidth on it? > For cases like what initiated this thread, actually. But, I'm not looking to increase the disc1.iso size, but separate the disc1.iso and memstick.img targets, which then can be created from different userland environments (one with /usr/bin/clang and one without, for example). But, I do agree with you that keeping the downloadable installer medium as small as possible (while still being usable for "rescue" cases like this) is ideal. Glen
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:09 UTC