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