Gentoo Archives: gentoo-dev

From: Ian Stakenvicius <axs@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] minimalistic emerge
Date: Fri, 08 Aug 2014 17:31:09
In Reply to: Re: [gentoo-dev] minimalistic emerge by Igor
2 Hash: SHA256
4 On 08/08/14 12:27 PM, Igor wrote:
5 > Hello Ian,
6 >
7 > Friday, August 8, 2014, 7:45:56 PM, you wrote:
8 >
9 >
10 > *> -----BEGIN PGP SIGNED MESSAGE-----
11 >> Hash: SHA256
12 >
13 >> Igor - you need to read the emerge man page.
14 >
15 >> "emerge -uDNav @world" is the recommended way to update your
16 >> system, because then you will stay in sync with all appropriate
17 >> updates in the portage tree. However, if you don't want to do
18 >> this, just "emerge -u @world" -- that will only update packages
19 >> in your world file, and will only force dependency updates when
20 >> the new version is required (based on minimum versions in package
21 >> dependencies). And if you only want to upgrade things piecemeal,
22 >> then use "--exclude [pkg]" to skip updates, or "emerge -1 [pkg]"
23 >> to only update an explicit list, or use /etc/portage/package.mask
24 >> to avoid updating to newer versions.
25 >
26 > *It's unreliable, if you update system on daily basis - the system
27 > will get unstable and eventually will not even boot. It will be
28 > up-to-date but not functional. UDEV was the latest example :-( The
29 > updated system requires constant human assistance and the number of
30 > CRITICAL bugs is always constant (heart beat bug affected the
31 > latest systems but not old). I know no server that is automatically
32 > updated with -uDNav @world and works for more than 6 months.
33 >
34 > I would do it but I know that each time @world updated - I'm in a
35 > possible trouble. I need to check all config files, all daemons for
36 > changes, boot managers, mdadmin, web servers, mysql, udev, and the
37 > surprise will happen when you boot next time. May be in in 300
38 > days, then you try to remember what was changed in 100 days, it's
39 > close to a hell.
41 Of course. Gentoo in and of itself does not provide a distro that is
42 out-of-the-box functioning at all times, like Debian or RHEL
43 does/tries-to*. Updates do and always will require administrative
44 maintenance, emerge (and paludis and pkgcore) is not a tool that's
45 meant to be used in an automated fire-and-forget way, and the portage
46 tree doesn't provide packages in such a fashion either. You will
47 always have to use your head when packages upgrade, as to the effect
48 that they will have on your system as a whole.
50 If you do want to push (server) updates in an automated way, then you
51 should have your own staging system that will build and host binpkg's,
52 including the necessary (manually vetted) configuration updates, and
53 have your servers pull those updates from the staging system. That
54 way, you're still doing the due diligence that is required for updates
55 - -and- you have a means of rolling these updates out in a
56 mostly-automated fashion across multiple systems (whether they be
57 homogeneous or not).
59 [* this is only my perception of those projects, i have little
60 knowledge of them, and what knowledge i do have is a decade out-of-date]
62 >
63 > Maintainers - don't have time to test packages against old
64 > versions, they just pull in the new versions in e-build with > each
65 > is doing that and the resulting update is an enormous surplus.
66 >
68 If a maintainer bumps the minimum version of an ebuild's dependencies,
69 then it's done so for a reason and this really shouldn't be
70 circumvented. However, standard portage updates (via --deep) will
71 upgrade those dependencies to the latest stable in-tree version
72 regardless of what the minimum version is in the ebuild. So the issue
73 that you seem to be complaining about here doesn't have anything to do
74 with maintainers and rather has to do with the way you're using emerge.
77 > *> If you're asking for something even lighter than what 'emerge
78 > -u
79 >> @world' will provide, on an automagic system-wide level, then i
80 >> think you'll need to author some detailed specifications as to
81 >> exactly what it is you want this new updating feature to do.
82 >
83 >> Please note, though, that we as Gentoo developers can't guarantee
84 >> that your system is going to remain stable if you don't update
85 >> --deep, because we can't test every possible combination of
86 >> every stable-keyworded dependency version against every package
87 >> -- not even a tinderbox makes that particularly feasible, there's
88 >> just too many permutations. I also am not sure at this time if
89 >> 'emerge -u' would
90 >
91 > *You need to know what packages are installed and how they're
92 > installed world wide. That is the only way to stabilize Gentoo
93 > architecture. Firing updates not knowing what happened - is the
94 > lack of feedback that is hurting gentoo development.
95 >
97 What? No. We are not going to only commit new ebuilds (or only
98 stabilize ebuilds) for libraries on the basis of what versions other
99 distros are currently using as stable, and building their entire
100 package tree against. If you want that, then what's the point of
101 using Gentoo in the first place? Gentoo's strength is in its ability
102 to use arbitrary library versions (within certain restraints as
103 specified by their consumers) for any dependency, and update them as
104 new updates (with new features or bug fixes) are released upstream,
105 and rebuild (when necessary) the packages that depend on them, so that
106 you obtain and maintain an integrated system image.
109 >
110 > *> upgrade dependencies when the version installed was removed from
111 > the
112 >> portage tree, and this may have multiple adverse effects on your
113 >> system long-term depending on why that older version was dropped
114 >> from the tree.
115 >
116 >> So, the recommendation remains that one should update the entire
117 >> system via -uDN in order to receive all of the updates available
118 >> for your entire dependency tree.
119 >
120 > *Is there any warranty that updated with -uDN system will remain
121 > full functional for 1 year? I have 100% warranty that not updated
122 > system is going to remain functional for 5 or 6 years. I have some
123 > with 7 years uptime.
125 If you -uDN daily/every other day/twice a week/weekly/monthly/whatever
126 *and* you *maintain* the system by doing the necessary configuration
127 changes and updates as you go, restarting services as necessary after
128 updates, etc. etc., then the system certainly can remain fully
129 functional. You *do* have to -maintain- the systems though. Read the
130 news items before updating so you know what configuration changes may
131 be expected of you, be proactive in putting those changes in place (or
132 push back some of those changes when they aren't necessary), pay
133 attention to what upgrades happen so that you arent blindly installing
134 a -major- package update (ie, a samba3 to samba4 type upgrade), and
135 you should be fine.
137 That said, no there is absolutely no warranty or guarantee. Gentoo
138 does not provide a linux OS "appliance" -- it provides all the tools
139 an parts you need to build your own appliance with very little manual
140 intervention (compared to doing it all on your own), but the
141 management and maintenance of that appliance is in your hands.
143 It's like by-hand kernel updating -- yes, technically you could 'make
144 olddefconfig && make install && reboot' (or similar) blindly, but the
145 likliness of your system continuing to work optimally or even properly
146 gets pretty slim over time if you don't pay attention to how things
147 have changed from one version to the next.
150 Version: GnuPG v2
152 iF4EAREIAAYFAlPlCU4ACgkQ2ugaI38ACPCcugEAl558Gs6jdcHbeT5J46Ty38cN
153 eMeYa3MLIcUuhggUmW0A/0yGvjpaQeZaD15Owjit/27h9GzPSYaU8EMjlQn9W1ii
154 =nHCM
155 -----END PGP SIGNATURE-----