Hi Juan, Juan Miscaro wrote on Mon, Nov 26, 2007 at 08:17:03AM -0500: > --- Nick Holland <[EMAIL PROTECTED]> wrote: >> Juan Miscaro wrote: >>> --- Ingo Schwarze <[EMAIL PROTECTED]> wrote:
>>>> The standard way to handle upgrades is to update the src >>>> on the master only, to build new release sets on the master, >>>> and to use the official upgrade process to install these >>>> new release sets on the clients. That way, none of the >>>> clients will ever need source code. You can extend this to cover ports and packages: The standard way to handle port upgrades is to update the ports tree on the master only, to build new binary packages on the master, and to use pkg_add -u on the clients. That way, none of the clients will ever need the ports tree installed. >>> I'm embarrassed to say that I was intending to build my >>> client systems locally. >> Save yourself time and work, make a release. > Well I've done that on the master and used the release to install the > client but I didn't think of using release sets to upgrade the client, > especially when it becomes a remote system. Not sure how to do that > (upgrade via sets remotely). Just unpack the sets? No, download the new /bsd.rd, boot it, select "upgrade", and tell it to fetch the install sets from your private server when it asks you where to get the install sets from. Alternatively, burn your self-built install sets onto your own CD and carry them with you when travelling around the field. The whole upgrade process is very similar to the install process, see the coverlet of your official OpenBSD release CD set for a nice example. >>> The ports tree can be useful though. >> eh. >> I keep telling myself that, but I hardly ever use it 'cept on a >> couple machines. Those are usually NOT machines I'm installing >> packages to. (i.e., I use the ports tree on my management >> console machines, but on actual production machines, I never use it. >> I can look at the tree on my machine I'm sitting at, rather than the >> machine I'm sshed into, find what I need to know, then pkg_add -i >> whatever...) > I don't get it. How did you go from installing from the ports tree to > using pre-compiled packages (pkg_add)? As far as i understand Nick, he is basically not using the ports tree at all, except for looking things up. Having the ports tree around on your desktop machine is nice so you can grep /usr/ports/INDEX and /usr/ports/*/*/Makefile when you feel like it. But when i need optional software, i install the binary package from a package repository - either a public mirror or, if needed, my own binary package collection, a private FTP server inside our intranet. My only machine having the ports tree is my build machine. But over there, it is only used to build committed -current ports nor yet available in snapshots, to test uncommitted -current ports found on ports@, to build modified ports i hacked into and to build completely new ports of so far unported software. >>>> Juan Miscaro wrote: >>>>> The trouble is that when I performed a test update of this code >>>>> there was a immense amount of downloading taking place. >>>>> This should not have been the case. >>>> Unless you tell us what you mean by "test update" (cvs update? >>>> which server? which command, exactly?) even guessing is difficult. >> unanswered important question. > I use cvsup to update my sources (to STABLE): [...] Hm, sorry, i'm not really experienced concerning cvsup. Maybe it's quicker than plain cvs, maybe the same argument still applies: Syncing a large tree might take some time, even when it finally turns out not that much of the stuff changed after all. > Thanks for your comments. You are welcome, Ingo -- Ingo Schwarze <[EMAIL PROTECTED]> Serverbetrieb usta.de / studis.de
