1 |
-----BEGIN PGP SIGNED MESSAGE----- |
2 |
Hash: SHA256 |
3 |
|
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. |
40 |
|
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. |
49 |
|
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). |
58 |
|
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] |
61 |
|
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 |
> |
67 |
|
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. |
75 |
|
76 |
|
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 |
> |
96 |
|
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. |
107 |
|
108 |
|
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. |
124 |
|
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. |
136 |
|
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. |
142 |
|
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. |
148 |
|
149 |
-----BEGIN PGP SIGNATURE----- |
150 |
Version: GnuPG v2 |
151 |
|
152 |
iF4EAREIAAYFAlPlCU4ACgkQ2ugaI38ACPCcugEAl558Gs6jdcHbeT5J46Ty38cN |
153 |
eMeYa3MLIcUuhggUmW0A/0yGvjpaQeZaD15Owjit/27h9GzPSYaU8EMjlQn9W1ii |
154 |
=nHCM |
155 |
-----END PGP SIGNATURE----- |