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.
--
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"
