The SMUP (single monolithic update procedure) was implemented several
years ago IIRC. At the time it was explained that there were
insufficient staff resources to continue doing QA for incremental
builds, even ones as simple as usr.bin/gzip. That said it is still just
as straightforward to it yourself.
What I wonder is why staff is so resource constrained? Is it
fundamentally due to a broken funding model? Are potential volunteers
turned away for not having submitted enough patches and other
questionable policy hurdles? Are there other organizational reasons
why such burdensome upgrades are left for end-users?
A lot of this maintenance hassle will someday be resolved with base
packages but even that project has been resource constrained. The
FreeBSD Foundation has not, to the best of my knowledge, commented on
these resource constraints or potential resolutions. Quarterly and
Annual reports occasionally mention them but only in passing. How
do we get someone on the Board/Foundation who is willing and able to
prioritize these important issues?
Roger Marquis
Hi,
Last years all Security Advisories regarding base system in the "update
your vulnerable system via a source code patch " section recommends to
rebuild a whole world instead of an affected part of a base system. This
is in a most cases an overhead.
For example 9 years old SA-11:04 [1] offers:
b) Execute the following commands as root:
# cd /usr/src
# patch < /path/to/patch
# cd /usr/src/usr.bin/compress
# make obj && make depend && make && make install
# cd /usr/src/usr.bin/gzip
# make obj && make depend && make && make install
What is a reason we stop to do it? I understand that the preferred way
now is a binary upgrade.
+1 I've been wondering this as well. What is the reason for it?
--
J.
_______________________________________________
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
