Date: Sun, 7 Dec 2008 18:39:09 +0100 From: "n j" <nino80@gmail.com> To: freebsd-questions@freebsd.org Subject: Re: [freebsd-questions] Looking @ upgrades mechanisms... Message-ID: <92bcbda50812070939v59afe196od1c8b6489b5a0d6c@mail.gmail.com> In-Reply-To: <200812012304.56334.beech@freebsd.org> References: <c88cc5730812012241i6ea540uc8a56f40c3d8237e@mail.gmail.com> <c88cc5730812012243j7a26d58bkec5cdb5fef799907@mail.gmail.com> <200812012304.56334.beech@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> versions. The packages for a particular branch tend to lag the updates by up > to a couple of weeks although they are built continually. If you want to stay > really up to date you need to keep your tree updated with portsnap or csup > (part of the base system) and compile them yourself. Another advantage to > compiling is you can choose options. The packages are always built with > default options which is generally OK, but not always optimal. On a discussion note, wouldn't it be nice (and quite possible based on the frequency of vulnerability reports on vuxml) to have a sort of "security" branch for pre-built packages? What I mean is, if you use -RELEASE package repository, you get the benefit of a large number of pre-built packages at a cost of them not being up to date. On the other hand, building all the packages all the time (i.e. using -STABLE repository) results in the mentioned couple of weeks lag, probably due to the sheer number of ports available. So, it would be nice to have a sort of -SECURITY branch (much like it existed before freebsd-update became part of base system) and make a dedicated package repository where only packages with reported vulnerabilities in vuxml would get (promptly and regularly) rebuilt thus giving people options of doing binary up-to-date upgrading without inflicting too much load on the package building machines. Thoughts anyone? -- Nino
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?92bcbda50812070939v59afe196od1c8b6489b5a0d6c>