Date: Mon, 12 Dec 2016 09:04:16 -0500 From: <scratch65535@att.net> To: freebsd-ports <freebsd-ports@freebsd.org> Subject: Re: The ports collection has some serious issues Message-ID: <kbat4c5qjm82isc2dvqku5bvgbfgpbe4e9@4ax.com> In-Reply-To: <20161212125557.GN2648@home.opsec.eu> References: <c5bc24cc-5293-252b-ddbc-1e94a17ca3a8@openmailbox.org> <20161208085926.GC2691@gmail.com> <odkr4cdf8dant07thrav2ojn7bng98noj9@4ax.com> <ba08610a-3536-b347-c802-ca134b296246@unfs.us> <aea50699-2938-0fee-38bc-1bcdf4b7f8cc@ShaneWare.Biz> <5s3t4c576qeivfr32d2j7u1fm8jkia97jf@4ax.com> <20161212125557.GN2648@home.opsec.eu>
next in thread | previous in thread | raw e-mail | index | archive | help
[Default] On Mon, 12 Dec 2016 13:55:57 +0100, Kurt Jaeger <lists@opsec.eu> wrote: >Hi! > >> >> On 12/11/2016 03:35 PM, scratch65535@att.net wrote: >> >>> I have to admit that I avoid ports if at all possible because >> >>> I've hardly ever been able to do a build that ran to completion. >[...] >> >Note that there are over 26000 ports, over 1600 port maintainers and >> >hundreds of third party projects get updated every day. While the port >> >maintainers spend a good portion of their spare time trying to keep it >> >building there will be times that some ports fail to build. >> >> Which, I think you must agree, is a prima facie case for >> lengthening the release cycle. > >While I can understand where this comes from, it can be read as >"slow down the world, it's too fast" 8-} Well, that part of the world is under our control, and it's currently not working at all well, so...? > >> Perhaps The Major Problem currently is that the makefile goes and >> fetches code chunks from sources that are out of our control. [...] > >> Contrast that with how it would be if the maintainer got one copy >> of every potential chunk at the beginning of the cycle and stored >> it in ports so that everyone who builds the port builds against a >> known-good set of bits. It would be both more stable and faster. >> But that's not how it's done. Why not? > >As far as I know: The idea was to track upstream, not try to become >upstream. Otherwise the changeset (distfiles) repositories would >be come much larger to maintain on the FreeBSD side. I'm sure that's true. But it's not working, and in fact can't work except by accident because it's uncontrolled. Your point about the distfiles repositories is well-made. How about storing them centrally, then, but only download them to the local boxes for the build. I.e., portsnap would fetch what it fetches now except for distfiles. Then if someone does some build, all the files for the build would be slurped from one of the portsnap.freebsd.org distfile mirrors. And if only the production-quality code were stored centrally--nothing beta or [shudder] alpha, that would drop the storage requirements considerably. I used to be appalled at seeing something being pulled in that was at v0.03 or something similarly horrible. People who like living dangerously with pre-alpha code can get their from the originators, just as they do now.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?kbat4c5qjm82isc2dvqku5bvgbfgpbe4e9>