Date: Fri, 30 Dec 2011 14:31:17 +0100 From: Polytropon <freebsd@edvax.de> To: RW <rwmaillists@googlemail.com> Cc: freebsd-questions@freebsd.org Subject: Re: Same version on binary packages and updated ports Message-ID: <20111230143117.7ed3e449.freebsd@edvax.de> In-Reply-To: <20111230131435.43bc218f@gumby.homeunix.com> References: <20111229161611.GA81214@chancha.local> <51AF4F0E-AD5A-4D0A-BC33-4C452B2D1650@mac.com> <20111229185325.GA56404@chancha.local> <20111230131435.43bc218f@gumby.homeunix.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 30 Dec 2011 13:14:35 +0000, RW wrote: > On Thu, 29 Dec 2011 19:53:25 +0100 > Walter Alejandro Iglesias wrote: > > > I really appreciate that you all, Jerry, Polytropon and Chuck, > > took your time to answer me. But I think some of you understood > > paragraphs like individual-separated statements, that's why you > > did not fully understand my question (my horrible English helps > > too :-)). > > > > Let's see if I can explain myself. > > > > I know that FreeBSD base system and 3rd party are "managed" > > separately. For RELEASE I meant the ports included in a fresh > > RELEASE install. The scenario is: what to do after a fresh > > RELEASE install. Once you updated the ports with 'portsnap fech > > extract update' you have newer versions at the port tree. Then > > you can upgrade the already installed software using > > portupgrade... But compiling! > > One strategy is to use csup to only update the port tree to release > tags and so use successive release packages as you update the base > system. You need to check portaudit for vulnerabilities. For such tasks, csup provides a good basis for explicitely specifying a RELEASE or security patch level. This can be applied to both the sources and the ports tree (of the corresponding date). > An alternative is to use stable packages. There are two problems with > this. The first is that whilst these packages will mostly work they are > not guaranteed to be compatible with release, or older stable, base > systems. You can eliminate this entirely by using stable and updating > world after updating the ports tree. A common rule is: If you use -STABLE for the OS, you want to keep your ports tree current and do security upgrades whenever neccessary (see portaudit for that functionality), or if the users of the production server require a certain version change. Using the ports infrastructure can also be helpful when you need to so something "extraordinary", like intendely installing an older port (see portdowngrade for this particular task) or fixing a port change from today to tomorrow (as this will show up in a csup delta, but not neccessarily as fast in a portsnap run). > The second problem is the variable lag between a port being > updated and the package becoming available. Frequent updating > exacerbates this problem. If you use portupgrade -P every day it will > probably never use a package file. In this case, I would also suggest using the compiling approach. Binary packages don't give you the flexibility to follow -STABLE or -RELEASE-p<level> that closely in time. > If it's for a production server, you might consider building your own > packages on a separate machine. You could also designate a jail for the building process (if the server has enough power) and either use the results generated in that jail for installation or follow the suggestion of using the packages generated in that jail (/usr/ports/packages will be populated by the "make package" command). However, as you're mentioning a _production_ server, it's always wise to test the updated software before bringing it into operation for that system. The idea of using a "mirrored server" for testing comes handy here. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20111230143117.7ed3e449.freebsd>