Gentoo Archives: gentoo-dev

From: Kevin <lists@×××××××××.com>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Wishlist: an automated package upgrade system with fine-tunable sysadmin control
Date: Wed, 26 Apr 2006 18:28:11
In Reply to: Re: [gentoo-dev] Wishlist: an automated package upgrade system with fine-tunable sysadmin control by Chris Gianelloni
1 Chris Gianelloni wrote:
2 > On Wed, 2006-04-26 at 12:29 -0400, Kevin wrote:
3 >> One thing that I'm pretty sure is currently not possible with portage,
4 >> however, and that I'd definitely like to see as a part of this idea is a
5 >> way of setting thresholds on version numbers of packages in portage such
6 >> that the automated upgrade system will only upgrade a package
7 >> automatically if the difference in version numbers between the installed
8 >> package and the newest available package in portage is greater than some
9 >> admin-tunable amount. For example, I might not want to upgrade emacs or
10 >> xemacs just because a new -r number becomes available. Maybe I don't
11 >> want to have such a big package upgraded automatically unless there is a
12 >> new major or minor version number.
13 >>
14 >> Thanks again to all the developers who have made Gentoo. It's a really
15 >> terrific distro.
16 >
17 > Jakub meant the portage-devel mailing list, not this one.
19 woops. when i saw portage/devel i figured one or the other... guess not...
21 >
22 > Anyway, most of this can be done already using /etc/portage files and
23 > some well-written cron scripts. You can lock down versions of specific
24 > packages quite easily using your own package.mask and package.unmask
25 > files, along with package.keywords.
27 Yes, and as I wrote, I'm aware of your points here, and I do use these
28 capabilities fairly extensively now, but it is not the sort of
29 fine-tunable system that I have in mind where I could inform the
30 automated-update-system (for lack of a better name) of my wishes in
31 terms of which packages are safe (in my judgment, as the sysadmin of
32 that particular box) to upgrade in an unattended manner and which are
33 not (at least, not unless I'm much less well-informed on Gentoo than I
34 believe myself to be, which I'm not denying might be true).
36 And unless I'm way off-base, the version-difference-threshold notion
37 described above is not implemented in portage now. Someone please
38 correct me if I'm wrong.
40 > However, one thing you can *never*
41 > do is assume that *any* package that has *any* kind of configuration
42 > files or is a library will *never* change in an incompatible way.
44 Well your comment is certainly true in the most extreme interpretation,
45 but the same thing can be accurately said about whether or not one
46 should assume that the sun is going to rise tomorrow or that the
47 universe won't disappear in a quantum fluctuation while you're sleeping,
48 but IMO, such extreme statements have little value in day-to-day
49 application. Everyone must make some assumptions about nearly
50 everything or it becomes nearly impossible to function. I make all
51 kinds of assumptions in administering computers and they almost always
52 make my life much, MUCH easier than it would be without the assumptions.
53 Sometimes they bite me, but only rarely. The key to success here is
54 having the judgment to know what is relatively safe to make assumptions
55 about and what is not. Judgment is something that only a human can
56 provide... not a computer. This is why I want greater and more granular
57 control over upgrading packages in Gentoo. Aside from the points you
58 make above (and I may be missing some other features currently present
59 in Gentoo), my choices now are, in the grossest terms: upgrade every
60 package by hand, one at a time, while sitting in front of the computer
61 (which is very close to what I spent last weekend doing) or do an emerge
62 world and hope for the best. IMO, that's not much control and does not
63 allow for the application of judgment except in the former option (which
64 is very, very time consuming).
66 >
67 > Basically, what you want is the assurances of a binary distribution that
68 > things will "just work" when upgraded,
70 No. Not true at all. And for that matter, binary distributions (in my
71 10+ years of experience with them) simply do NOT just work: not for
72 Slackware, not for Yellowdog, not for SuSE, not for Redhat, nor
73 Mandrake, nor any of a dozen others I've tried. I found that quite the
74 opposite was true which was one of the reasons I switched to Gentoo
75 (which I've found, usually DOES just work after upgrades; not always,
76 but usually---and this is a credit to the Gentoo developers).
78 What I really want is to make the process of maintaining Gentoo boxes
79 over the long term easier (IOW: less time-consuming) than is now true,
80 by adding some functionality that AFAICT does not now exist which would
81 allow me to automate some things, turn off automation of other things,
82 and as the sysadmin, have control over what those things should be. In
83 my mind at least, the central theme in Gentoo of choice dovetails nicely
84 with what I'm trying to describe here: control and choice that is highly
85 fine-tunable by the owner of the box in regards to package upgrades.
87 I'm not a member of the portage-devel mailing list so I'm going to drop
88 this now. If someone here is a member of both, then please feel free to
89 cross-post this thread to whatever forum is most appropriate for it.
90 After spending 30-45 minutes trying to help improve Gentoo by posting a
91 new (AFAICT) idea in bugzilla and again here, I feel like I've done
92 enough. IMHO, this is an idea that would add great value to Gentoo and
93 I can't help but think that many sysadmins who must maintain many boxes
94 would agree, but I have no particular attachment to the idea that would
95 make me want to go around every mailing list under the sun trumpeting my
96 idea to anyone who will listen. I'm just posting an idea that seemed
97 like a good one to me. The devs may take it or leave it as they see fit.
99 Regards,
100 Kevin
101 --
102 gentoo-dev@g.o mailing list