Date: Wed, 03 Dec 2014 00:04:00 +0100 From: Mathieu Arnold <mat@FreeBSD.org> To: "Russell L. Carter" <rcarter@pinyon.org>, freebsd-ports@freebsd.org Subject: Re: ports back channel Re: perl5.16->5.18 Message-ID: <539891BCDEB497060868026C@atuin.in.mat.cc> In-Reply-To: <547941C6.9010505@pinyon.org> References: <5478DE06.1040208@pinyon.org> <CAN6yY1tEPFdjxv5KZ3bS%2Bh9PZ9ObmYhpa=KE7NZbUCdstzv%2B-Q@mail.gmail.com> <54790A05.3070303@pinyon.org> <547941C6.9010505@pinyon.org>
next in thread | previous in thread | raw e-mail | index | archive | help
+--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. | 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. -- Mathieu Arnold
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?539891BCDEB497060868026C>