1 |
On Sun, Jan 30, 2022, 01:36 Andreas Fink <finkandreas@×××.de> wrote: |
2 |
|
3 |
> Hello, |
4 |
> |
5 |
> I have a couple of systems that I do not update regularily (some not |
6 |
> even for years). But then sometimes I feel, hey I should do an update. |
7 |
> I have one master build server which builds packages and keeps them as |
8 |
> binary packages, annd all my systems pull the gentoo portage tree from |
9 |
> this master build server, additionally also the configs in /etc/portage |
10 |
> is the same amongst all boxes, i.e. use flags et al are all the same. |
11 |
> |
12 |
> Now comes the misery when I want to update an old box, because of |
13 |
> unsupported EAPI and what not. One way that I used in the past was to |
14 |
> extract a stage-3 tarball over the existing root system, and then do |
15 |
> the upgrade, which works to some extent, but it does not seem right. |
16 |
> Coming now to my question: Is it possible to start a live gentoo system |
17 |
> with a recent portage version and then tell portage that it should |
18 |
> install the packages in /mnt/gentoo (which is the real system I care |
19 |
> about). I have heard about the prefix project, but I'm not sure if this |
20 |
> is exactly what I want. |
21 |
> Maybe a second approach would be to get the minimal set of binary |
22 |
> packages from the master build server and extract them manually, such |
23 |
> that I end up with a recent enough portage which supports all EAPIs |
24 |
> that are in the tree. But I have no clue how to get the minimal set of |
25 |
> packages that I would need to extract. |
26 |
> |
27 |
> Does anybody have other approaches (besides starting from scratch)? |
28 |
> |
29 |
|
30 |
|
31 |
Portage is supposed to offer an upgrade path for any system up to a year |
32 |
out of date. |
33 |
|
34 |
If you grab the version of portage from the last upgrade time of the system |
35 |
being updated plus 6-12 months (however daring you feel like being) you |
36 |
should be able to upgrade it that much without needing to do a lot of |
37 |
fiddling. |
38 |
|
39 |
Repeat until you're updated. |
40 |
|
41 |
|
42 |
Going forward, you could consider having your build host take a snapshot / |
43 |
backup of the binpkgs it builds every 3-6 months, with the associated |
44 |
portage tree, so that you can use those to update your sporadically updated |
45 |
machines. |
46 |
|
47 |
|
48 |
I strongly recommend against overwriting your system with a stage3. Any |
49 |
package that has a changed list of files will leave orphans behind. And |
50 |
finding them all will be pretty dang hard. |
51 |
|
52 |
|
53 |
Personally I just make a point to keep my not very large number of machines |
54 |
updated, but I do it by hand. You might want to look and see if anyone's |
55 |
written any scripts that automatically update + restart services / reboot |
56 |
periodically, and email you upon problem |
57 |
|
58 |
> |