Date: Wed, 03 Dec 2014 11:40:00 -0700 From: "Russell L. Carter" <rcarter@pinyon.org> To: Mathieu Arnold <mat@FreeBSD.org>, freebsd-ports@freebsd.org Subject: Re: ports back channel Re: perl5.16->5.18 Message-ID: <547F5900.3000904@pinyon.org> In-Reply-To: <539891BCDEB497060868026C@atuin.in.mat.cc> References: <5478DE06.1040208@pinyon.org> <CAN6yY1tEPFdjxv5KZ3bS%2Bh9PZ9ObmYhpa=KE7NZbUCdstzv%2B-Q@mail.gmail.com> <54790A05.3070303@pinyon.org> <547941C6.9010505@pinyon.org> <539891BCDEB497060868026C@atuin.in.mat.cc>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Mathieu, Thank you for responding. I've thought about this over the last few days a bit, and I first want to commend you for the large efforts you and your collaborators are making to improve the port system. Already I have noticed positive changes, very impressive. Further comments inline. On 12/02/14 16:04, Mathieu Arnold wrote: > > > +--On 28 novembre 2014 20:47:18 -0700 "Russell L. Carter" > <rcarter@pinyon.org> wrote: > | The little major one is, a perl5 upgrade should not require > | rebuilding ~2/3 of the ports tree. Maybe I'm off a bit, but > | I don't think by a material amount. This turns out to be the > | minor problem. I don't actually care, as long as the installs > | respect my configs, have at it. It just spends an awful lot > | of cpu time doing, what? Updating a version database? > > Yes, a major perl version upgrade should not require to rebuild > everything, and the dozen commits I made to Perl and the ports > framework this week, and a few other to come, will make sure you > have to rebuild only stuff that really needs rebuilding. But at one > point, to go from "you have to rebuild everything" to "you only have > to rebuild those" I needed to move things around, and as stuff > moved, you *do* have to rebuild everything this time. Next time, > you will only need to rebuild ports that are linked with > libperl.so.xx.y because other ports will not change. Excellent. I realized after thinking about it that I was basing my judgements on experience with debian packaging over 15 years. And they have gotten to their current advanced state by a lot of iterations, and occasionally some pain. It is correct, I think, to get the dependencies sane at the beginning and then to gradually back off so that more and more of the tree can be left out of the direct dependencies path(s). > | I don't deny that the possibility exists that the fix > | is trivial: that's not the point. The point is that to regain > | painless access to the entry into the security domain many (few?) > | rely on, I now have to search for this (hopefully) trivial fix. > > Well, I could maybe have changed the rebuild everything (like > portupgrade -f -a) to rebuild everything that needs upgrading as > I've bumped PORTREVISION on like 5k ports that were modified, plus > everything that depends on libperl.so, but it was easier to just say > everything than give a strange, complicated, and prone to errors, > script that would do it. > > | You absolutely cannot break this because there are vulnerable > | people in the field. Maybe you say they should never update, > | but, what happens on a compromise? > | > | So these decisions are getting made outside of freebsd-ports. > | Where are they getting made? I am uninterested in chiming in > | except on something like pinentry. > > The pinentry thing was done, I think, in the committer's head that > made the change (I'm not sure what exactly went wrong, but at the > time, gnupg was upgraded and it was bad.) As for the NewPerlOrder > change, I announced them on freebsd-perl@, I did a few code reviews, > which nobody reviewed. I don't remember if I also chimed in here > too. > Upon further review, I have changed my mind :-). I think that if a person really requires a guarantee that a package will work, especially, say for their security domain, they should take responsibility for that package and maintain it outside of the distribution package system (any distribution of an OS: *BSD, linuxen, etc.) The thought experiment that led me to this conclusion is: suppose that my personal mission critical toolbox contains two or more packages with (mostly) independent dependency trees, embedded in a very fast evolving package system (100s, 1000s of commits/week). To make it concrete, suppose I require that gnupg et. al. not fail, and that I want to track the enhancements that Adam Langley's team puts into chromium (and later firefox). No matter how conservative I am, I cannot without significant effort guarantee that gnupg will not fail. Every pkg upgrade will pull it along too, as changes to it evolve. This has very little to do with the packaging technology, quality of team, etc. It's all about the fact that software, including software packaging, inevitably fails. So the right thing to do is make sure, if it matters, that I'm the one responsible. This has unpleasant implications for the hope of safe, pervasive use of secure communications packages, but that's a side issue... Just to reiterate, thanks to you and the rest of the ports team for the huge efforts you do. Regards, Russell
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?547F5900.3000904>