On Tue, 27 Jun 2017 18:16:01 -0500, Mark Linimon <[email protected]> wrote:
>On Tue, Jun 27, 2017 at 04:53:36PM -0400, [email protected] wrote: >> Since that's what I integrate for my dev use, I'd be happy to >> take a zero'th-order cut at defining it, if nobody else wants to. > >Fine. See http://www.lonesome.com/FreeBSD/poudriere/subsets/ for what >I use. I'm not particularly interested in maintaining it as a general >set of files, but if someone can build on it, fine. Okay, I'll hae a keik. > >> By "unnecessary", Mark, I mean the fact that the bits are not >> controlled locally, and thus potentially change from moment to >> moment such that it's impossible to guarantee that two people >> building the same app with the same options on two different >> days, or even hours, will get the same result. > >I don't understand this. > >The distinfo mechanism is the solution for this problem for released >code. > >If people are relying on "whatever is in git at the moment" to >mean "release", well then that's upstream not understanding what >is meant by "release". Either educated them or fork their code >and become the new upstream. No, I'm talking about how when trying to build a port, even if using only the defaults, the process often fails to run to completion. And the failure is nearly always because some glop of bits being fetched from godknowswhere.edu has gone missing, or has been upped and is now the wrong version as far as the makefile is concerned, or has some other problem. Since I believe that 90% or more of our maintainers are conscientious and build at least the default config, I can only suppose, when the make fails, that somebody over at godknowswhere.edu decided to do something ad-hoc, and that "something" broke the build. This happens so often that I don't even try to build from ports any more ---my own work already supplies more craziness than I can use. > >> Switching to a central repository model, where the bits are >> fetched from around the globe only once per cycle, sanitised, and >> thereafter read only from the repository, would drop the number >> of file-not-founds and wrong-versions down pretty close to zero. > >Again, I simply don't understand this. If we controlled the bits from which ports were built, then nobody (I hope!!) would be changing them in an ad-hoc way, which *should* make every build run to completion without file-not-found etc. > >> >No one has ever done the work on "most minimal set of dependencies" >> >in the ports tree -- and that's because it's hard work. Add to that >> >the fact that the technology has never supported partial checkouts >> >and it complicates things. >> >> No argument from me! IMO a big contributor to the problem is >> that the bits haven't been normalised and integrated into >> libraries. So the process is frankensteinean: odds and bobs >> dredged up wherever they can be found and stuck together in hope >> that they'll cooperate. > >And this is where the hard work lies. > >By comparison, defining "which ports are canonical" is easy. > >IMHO. I can only repeat that you'll get no argument from me! But that's the basic advantage of libraries: do the hard work once, benefit from it forever (fsvo "once" and "forever"). Or do the work forever, and benefit each time only once. _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[email protected]"
