In message <CANCZdfrr6-s+h-6k5bSA_QDe-9GSoGnZjpJEKBZV0sQ5_xzD=a...@mail.gma il.com> , Warner Losh writes: > --0000000000005c05ef0585f2f684 > Content-Type: text/plain; charset="UTF-8" > > On Sun, Apr 7, 2019 at 9:35 AM Cy Schubert <cy.schub...@cschubert.com> > wrote: > > > In message <201904071510.x37fa7tm050...@gndrsh.dnsmgr.net>, "Rodney W. > > Grimes" > > writes: > > > > On April 7, 2019 7:11:52 AM PDT, Shawn Webb < > > shawn.w...@hardenedbsd.org> wr > > > ote: > > > > >On Sat, Apr 06, 2019 at 09:34:26AM +0000, Mariusz Zaborski wrote: > > > > >> Author: oshogbo > > > > >> Date: Sat Apr 6 09:34:26 2019 > > > > >> New Revision: 345982 > > > > >> URL: https://svnweb.freebsd.org/changeset/base/345982 > > > > >> > > > > >> Log: > > > > >> Introduce funlinkat syscall that always us to check if we are > > > > >removing > > > > >> the file associated with the given file descriptor. > > > > >> > > > > >> Reviewed by: kib, asomers > > > > >> Reviewed by: cem, jilles, brooks (they reviewed previous > > version) > > > > >> Discussed with: pjd, and many others > > > > >> Differential Revision: https://reviews.freebsd.org/D14567 > > > > > > > > > >Hey Mariusz, > > > > > > > > > >Is __FreeBSD_version supposed to be bumped after adding new syscalls? > > > > >I can't remember off-hand. > > > > > > > > > >Thanks, > > > > > > > > I don't think so. Why force the rebuild of all ports through poudriere > > over > > > something that would never affect any of them? > > > > > > So that you can if version >= foo to know it is safe to use the new > > syscal? > > > Or if version < foo you must use the old way. > > > > Granted. However we do need something to avoid gratuitous rebuilds of > > ports. > > > > Personally, my poudriere script adjusts the pkg version > > ($JAILPATH/data/packages/${JAIL}-${PORTS}/.building/.jailversion) with > > that of the jail version (reported by poudriere jail -i -j $JAIL), > > rebuilding all ports when I (the human) determines when the machine > > should rebuild all ports with -c. > > > > In that regard FreeBSD version bumps occasionally seem a little > > gratuitous. Using the same indicator to tell whether software should be > > able to use a new feature and when ports build infrastructure should > > summarily delete all packages forcing a rebuild of absolutely > > everything is probably not the best. > > > > Just throwing out an idea, what if poudriere considers the first N > > bytes of __FreeBSD_version significant? Having said that, looking at > > __FreeBSD_version, I don't think we have enough digits to do what I was > > planning on suggesting. But, you get the idea of what I'm driving at. > > Maybe a new macro such as __FreeBSD_ports that is incremented every > > time a change that affects ports? > > > > Anyhow, I'm not too terribly concerned as what I have (selfishly > > speaking) works. But we may as a group might want to consider this at > > some point to build some efficiency into the ports part of the equation. > > > > We generally bump the version around the time we add a syscall. This allows > any wrappers to call it or not based on the kernel version and avoid a > SIGSYS when we're doing forward compatibility hacks for whatever reason. > > The current overloading of __FreeBSD_version is unfortunate. We've been > quite liberal over the past 2 decades at bumping it because it's free to do > so. Or so the thinking has been. I personally think we should continue to > do so, but maybe look at piggy-backing those changes we can if someone else > bumped it in the last few days. To give some perspective, in the ~120 days > since we branched, we've bumped it 17 times. This is more or less weekly, > which suggests we don't have a problem that we need to optimize too much > here. > > If Poudriere wants to optimize building, I'd suggest that you have a > command line argument / config file thing that sets the maximum skew. > Normally, you could set it up to be pretty tolerant, but if you knew > something was a big deal, you could then crank down to intolerant. The > current setting of '1' for this skew should be the default.
It's not that simple. A skew may miss an important change to base that will affect ports. Having resulting packages that segfault could be unacceptable outcome. An argument to ignore the jail/pkg version comparison or arbitrarily update it (like my script does) would solve this. However someone not monitoring base commit log commits, an arbitrary argument to poudriere could result in unnecessary mailing list noise or bugzilla tickets, both of which are time wasters. > > I'm not sure a FreeBSD_ports would scale. How do you know a port won't need > to know about the new syscall? It's from Linux, and there may be some ports > that use it if available. As a src committer, I've not easy way to know > (and no hard way to know that's not a full exprun). That's the other problem. Not everyone will know how a change may affect applications. I suppose the best might be a poudriere flag or config option to ignore jail and pkg version differences and let the human decide. Not all changes affect all ports and those that do should have have a portrevision bump anyway, which BTW is sometimes done. My making kerberos private in base is one such example. There are quite a few ports affected. The exp-run only identified a few who's options don't need kerberos in their default configuration. The more I look the more I discover. The base part of the project was easy (and pretty much ready to commit might I add). Ports OTOH tedious and still much to do. In the very worst case a version bump hardly scratches the surface ... unfortunately. I don't think we can answer this here. Maybe this rises to the level of a developer summit topic one year. -- Cheers, Cy Schubert <cy.schub...@cschubert.com> FreeBSD UNIX: <c...@freebsd.org> Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. _______________________________________________ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
