https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=285253
Chad Jacob Milios <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #5 from Chad Jacob Milios <[email protected]> --- (In reply to Gleb Popov from comment #2) has this finally become the project's official position? i admit i do not stay well read on the mailing lists but i do read everything put in CHANGES. i havent seen anything to that effect and it looks like the handbook section 5.2.3.1 reads the same as i remember it. actually come to think of it, i didnt realize it said "that includes changes that only affect a package built with non-default options." is our make and our shell no longer a "supported" ports build tool? i realize for many years it hasn't been the "cool" way to do it anymore, but time and time again i've sought assurance and been assured that poudriere will not become a mandatory requirement to utilize the ports tree effectively. my site has yet another such tool, developed internally and maintained since the FreeBSD 6 pkg_install days. it has always relied on a change of PKGNAME (of which PORTREVISION is a component) as signal it's necessary to rebuild a port. save for the occasionally overlooked bump or a non-default optional dependency here and there, it's always reliably kept our rollout up to date with dynamic links intact and it ties into our workflow in a way that is entirely out of scope for poudriere, synth or portmaster. if it "should be taught to consult pkg provides/requires" was there a notice issued that might point me in the right direction? what relationship(s) necessitate i should cascade rebuilds? (whenever LIB_, RUN_, or BUILD_DEPENDS changes, just to be safe?) believe me, i'm not resistant to change in this direction. i would love it if we're ready to stop all the obligatory PORTREVISION bumping commits. i'm not opposed to enhancing our tooling here to detect staleness of same-named packages by other conditional logic. the only reason we haven't is since 5.2.3.1 still reads as it reads. i'll be glad when we usher in this better way of doing things, i just got to say i was unprepared. without commits like a347a92e i too would've had a bunch of broken packages and before reading your comment #2, arrowd@, i probably would have been at a loss to quickly realize why -- You are receiving this mail because: You are the assignee for the bug.
