Hi, I'm on the list, so please...
On Sun, 04.07.2010 at 12:22:21 +0100, Stuart Henderson <[email protected]> wrote: > On 2010/07/04 11:18, Toni Mueller wrote: > > I can go. In many cases, this works just fine. > > In many cases, it works, but also in many cases, it breaks. right. I didn't say anything different, did I? And I only wanted to solve a problem with such a case where it doesn't work that well. > You're also at some risk of packages not getting updated where they > need to be if you later do a binary package update (e.g. when moving > to a new OS version). Right. But I rather track these changes myself, than rely on OS updates. If you want to see one instance of a _real_ problem, take a look at the FF port (3.0.18, last I looked, and no, I'm not using it). > Note that the security fix in nginx 0.7.67 is only a problem on Windows. Ok. Right. I missed the "Windows only" part, but was also impressed by the long list of fixed bugs in 0.7.66 which I also got by upgrading to 0.7.67. Also, I only mentioned nginx because it is an example of how upgrades often tend to work: very smoothly. > IMO William has been doing an absolutely *great* job handling security > updates for -stable ports, at first unofficially, and for the last > couple of releases within the project itself. I don't want to say something different, and I've probably selected a not-so-illustrative example because William actually *does* something really good. But this is not the standard situation with OpenBSD, and sometimes, (at least) I have functional requirements which prompt me to upgrade a certain package in between releases as well. > Binary packages aren't provided for -stable, but if you're running the > same packages on several machines it's well worth setting a plist file > and running your own package builds I'll have to look at this 'plist file' thing, but so far manually toured the ports tree for packages that I need, build them, put them on my local mirror, and install from there on several machines, yes. Only that this is currently a manual process, and I'm doing it only for i386 and amd64, and I also feed my local upgrades to this mirror as well. > - e.g. you can do something like > cd /usr/ports && make package SUBDIRLIST=/usr/ports/infrastructure/plist/mine Oh :) > You can then point other machines at the repository of built packages > with PKG_PATH=scp://host/path/to/arch/ and keep them all in sync. I have something different, but similar: MYNET=1.2.3 M="`uname -m`" R="`uname -r`" PKG_PATH="http://ftp.spline.de/pub/OpenBSD/$R/packages/$M/:http://mirror.hostfuss.com/pub/OpenBSD/$R/packages/$M/:http://ftp.wu-wien.ac.at/pub/OpenBSD/$R/packages/$M/:http: //anga.funkfeuer.at/pub/OpenBSD/$R/packages/$M/:http://ftp-stud.fht-esslingen.de/pub/OpenBSD/$R/packages/$M/:http://artfiles.org/openbsd/$R/packages/$M/"; if [ `route -n get default |grep -cF 'gateway: ${MYNET}'` -eq 1 ]; then PKG_PATH="http://download.oeko.net/sw/obsd/dist/$R/packages/$M/:$PKG_PATH"; fi This way, I get an appropriately set PKG_PATH for local and most remote machines with one setup, at least for -stable. If bandwidth permits, I'm not adverse to granting public access to the repository, but currently I'm not so sure, and I am also not so sure that my package building meets "your standards" (eg. "you" advise against private package building at most any occasion). > I heard of at least one person doing this with pkg_add -u run from > a cron job. (I expect the best methodology in production would be > to build, test on one machine, then move to the common repo if it's > good to go into automated updates). I don't upgrade automatically, but stash my packages on a local repo server. > And if you're running a small number of machines, it might well > be simpler to just run -current and use package snapshots, maybe > just updating the OS and installed packages when you need something > new. I can't run -current, as I don't yet have enough resources to catch enough of the fallout (see eg. the pfctl anchor issue a few weeks ago). > The well-staffed projects tend to keep ancient releases around > forever on life support (ever looked at software versions in RHEL?). I currently have the mixed pleasure to work with SLES, and will probably RSN have the 'opportunity' to work with CentOS as well... Also, I'm using Debian extensively, which some people think is ancient by definition, too. > The volunteer projects tend to be a lot more up-to-date but at > the expense to the user of having to put a bit more time into > keeping up with everyone else working on the system. You're preaching to the choir here. > It doesn't make an actual difference for some arch, but this should > be `arch -s` rather than `uname -m`; packages are built per CPU arch > rather than machine arch. (e.g. powerpc not macppc, arm not > armish, mips64 not sgi, etc). Ok. I wasn't aware of the difference. Thank you! -- Kind regards, --Toni++
