On Tuesday 16 Aug 2016 12:24:40 Michael Mol wrote:
> On Tuesday, August 16, 2016 11:19:27 AM Rich Freeman wrote:
> > On Tue, Aug 16, 2016 at 11:02 AM, Michael Mol <mike...@gmail.com> wrote:
> > > My workstation updates on a cron job every day at 6PM. I check my email
> > > in
> > > the morning to see if it ran into any trouble, correct whatever it
> > > complained about, and let it try again the next evening.
> >
> > I think you're better-off building binary packages at night and
> > installing them during the day. I'm not really keen on having Portage
> > do whatever it wants. It doesn't happen all that often but sometimes
> > I end up with a proposed downgrade that I'd prefer that it not do.
> >
> > I can't tell you who I stole this script from (one of the lists):
> >
> > #!/bin/sh
> >
> > LIST=$(mktemp);
> >
> > emerge -puD --changed-use --color=n --columns --quiet=y --changed-deps
> > --with-bdeps=n world | awk '{print $2}' > ${LIST}
> >
> > for PACKAGE in $(cat ${LIST});
> > do
> >
> > printf "Building binary package for ${PACKAGE}... "
> > emerge -uN --quiet-build --quiet=y --buildpkgonly ${PACKAGE};
> > if [[ $? -eq 0 ]];
> > then
> >
> > echo "ok";
> >
> > else
> >
> > echo "failed";
> >
> > fi
> >
> > done
> >
> > It can only get one level deep when there are dependencies. So, if
> > you have a KDE update you'll still do a lot of building during the
> > day. But, at least you won't be building kdelibs. And this is really
> > nice when chromium comes along with an update.
>
> So, here's my crontab entry. It's not necessarily the most efficient, but
> since I'm not around to wait on it, I don't really care; it works.
>
> *0 18 * * ** */usr/bin/eix-sync >/dev/null; /usr/bin/glsa-check --list ;
> /usr/sbin/perl-cleaner all ; /usr/sbin/python-updater ;
> /usr/sbin/haskell-updater ; /usr/bin/emerge -uDN @wor*
>
> The eix-sync, when backed by git, is really, really, really noisy, so I
> >/dev/null it. There's a ridiculous amount of stuff in the output every
> night. Though that may be because of my EMERGE_DEFAULT_OPTS:
>
> *EMERGE_DEFAULT_OPTS*=*"--tree --with-bdeps=y --keep-going --quiet-build=y
> --deep -- unordered-display --load-average 3 --jobs=3 --rebuild-if-new-slot
> y"*
>
> In the end, it's been working for me for quite a long time. I've been doing
> this (or something like it) for well over a year without it hosing my
> system. I even have it rolling updating KDE Plasma, KDE Applications, KDE
> Frameworks and Qt, though that takes about 450 lines in
> packages.accept_keywords.
>
> If I were to automate something for servers, it'd be a much more intense
> process, with tight constraints on versioning, integration with application
> unit tests and further integration tests at each step. (Something I'd
> absolutely *love* to do, but no way I'm going to have time for setting that
> up right now. So it's yum-cron on non-critical servers, and manual zoned
> rolling updates on critical ones.)+1 for building binary packages offline in a VM/container and updating your production server once you've tested all works as intended. Keeping previous versions of binary packages also means you can revert back to a working combination if you need to. The longest I've taken to update a server was around 6 months - I was planning to retire it, but plans changed. If anything it tested my memory, because I came across each and every problem I had come across when I was updating my other systems in the previous 6 months. ;-) These days I update every week or two, depending on the system in question. I wouldn't leave it longer than 3 weeks. I think 3 months could be pushing it, depending if any major changes happened in between and if you know what you're doing. The scripts provided above will help you automate the process, although TBH it only takes a few minutes to run these yourself. Just my 2c's. -- Regards, Mick
signature.asc
Description: This is a digitally signed message part.
