Date: Fri, 20 Jan 2017 09:39:06 +0100 From: Andreas Nilsson <andrnils@gmail.com> To: Glen Barber <gjb@freebsd.org> Cc: "O. Hartmann" <ohartmann@walstatt.org>, Matthias Apitz <guru@unixarea.de>, Current FreeBSD <freebsd-current@freebsd.org> Subject: Re: ISO image: where is the CLANG compiler? Message-ID: <CAPS9%2BStqRW3rg%2BOsLA38z-aKFV0ixRROB6esY0xccmvq6M2HTQ@mail.gmail.com> In-Reply-To: <20170119195843.GI1451@FreeBSD.org> References: <20170118101915.523d7d7b@freyja.zeit4.iv.bundesimmobilien.de> <20170118123515.GE58505@zxy.spb.ru> <20170118160801.229b4134@freyja.zeit4.iv.bundesimmobilien.de> <20170118153832.GA6905@c720-r292778-amd64> <20170118203726.7dea0515@thor.intern.walstatt.dynvpn.de> <ce772c1c-7506-6488-a6ae-6b95b2be8a20@freebsd.org> <20170119055816.GA2184@c720-r292778-amd64> <20170119101636.5537f4fd@freyja.zeit4.iv.bundesimmobilien.de> <20170119191000.GG1451@FreeBSD.org> <CAPS9%2BSs2b66eQYOe7_dfbgMo3mUdtYO_wwQi7cdM9TOshj9-Kw@mail.gmail.com> <20170119195843.GI1451@FreeBSD.org>
index | next in thread | previous in thread | raw e-mail
On Thu, Jan 19, 2017 at 8:58 PM, Glen Barber <gjb@freebsd.org> wrote: > 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@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 > > Good good. I am in no way opposed to the "infrastructure" change of separating the targets, sounds like a bit of makefile-fun actually. And having tools to create memsticks from ones preferred environment would be sweet. Maybe someone could add a target in the makefiles for a rescue image, which basically would be the complete FreeBSD system one would get after untaring base, kernel and src? Best regards Andreashome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAPS9%2BStqRW3rg%2BOsLA38z-aKFV0ixRROB6esY0xccmvq6M2HTQ>