| 1 |
On Thu, Jul 6, 2017 at 8:55 AM, Harry Putnam <reader@×××××××.com> wrote: |
| 2 |
> Rich Freeman <rich0@g.o> writes: |
| 3 |
> |
| 4 |
> "I also have gentoo pre-build binary packages where it can |
| 5 |
> overnight..." |
| 6 |
> |
| 7 |
> Not so much interested in binary... now that I see its really sort of |
| 8 |
> a non-starter for someone looking to avoid `emerge world' where |
| 9 |
> posssible, but I am interested in how your overnight runs are done, |
| 10 |
> the details, as they might apply to getting parts or all of an update |
| 11 |
> done unattended. Perhaps parts of your system can be adapted for use |
| 12 |
> where emerging all or parts of an update are the goal. |
| 13 |
|
| 14 |
I would tell you to search the list archives, but I really struggle to |
| 15 |
get Google to find anything there. |
| 16 |
|
| 17 |
At night I run a script which does an emerge --sync, emails me the |
| 18 |
output of emerge -pu world, and then tries to build binary packages of |
| 19 |
everything in it. |
| 20 |
|
| 21 |
The next morning I read my email to see what is to be updated, and if |
| 22 |
I'm happy I just do the emerge with a -k to use binary packages where |
| 23 |
available. |
| 24 |
|
| 25 |
I'll detail the scripts below since searching is not turning out well. |
| 26 |
|
| 27 |
> Can you flesh out some of the details? Especially the `where it can' |
| 28 |
> part. How do you know what can or or can't be done unattended? |
| 29 |
|
| 30 |
The issue is when there are layers of dependencies being built. If |
| 31 |
package A and B need to be updated, and B depends on A at build time, |
| 32 |
then portage can only create a binary package for A, unless you want |
| 33 |
it to actually install the package. I'm not building these in some |
| 34 |
kind of chroot or container - I'm using --buildpkgonly so it never |
| 35 |
gets installed. |
| 36 |
|
| 37 |
I guess another option would be to spin up a container/etc, do all the |
| 38 |
building and packaging, and then destroy the container. Then I'd have |
| 39 |
a complete sent of binary packages. I should think about that, though |
| 40 |
I'd probably want it to use a snapshot of my root when doing so and |
| 41 |
that could get tricky (since my host isn't intended to be used as a |
| 42 |
template). |
| 43 |
|
| 44 |
If you wanted to do a full unintended install there would be no issues |
| 45 |
at all, other than the risk that you might walk in and find the |
| 46 |
computer not working and have to figure out why. I prefer to review |
| 47 |
my updates before installing them - Gentoo has gotten a LOT better at |
| 48 |
this stuff but it isn't Debian stable or RHEL/CentOS. |
| 49 |
|
| 50 |
Here are my scripts. |
| 51 |
This does an emerge sync (called from cron): |
| 52 |
https://github.com/rich0/rich0-gentoo-scripts/blob/master/emergesync |
| 53 |
|
| 54 |
This does the package builds (called from previous script): |
| 55 |
https://github.com/rich0/rich0-gentoo-scripts/blob/master/buildupdates |
| 56 |
|
| 57 |
This package installs the updates (called manually after I review the |
| 58 |
emailed proposed changes): |
| 59 |
https://github.com/rich0/rich0-gentoo-scripts/blob/master/instupdates |
| 60 |
|
| 61 |
The whole thing could be refactored and cleaned up, since the emerge |
| 62 |
parameters are hard-coded in each script. But, it is good enough for |
| 63 |
my purposes. These are very safe to use since nothing gets installed |
| 64 |
unless you ask for it. It is nice having portage build chromium |
| 65 |
overnight and then I just do a 30 second install the next morning. |
| 66 |
However, for something like a qt/kde update you're still going to |
| 67 |
watch a lot of stuff build. If all it saves me is kdelibs I'll |
| 68 |
consider it a win. |
| 69 |
|
| 70 |
-- |
| 71 |
Rich |
Archives