Re: [gentoo-dev] Wishlist: an automated package upgrade system with fine-tunable sysadmin control

[Kevin]

Chris Gianelloni wrote:
> On Wed, 2006-04-26 at 12:29 -0400, Kevin wrote:
>> One thing that I'm pretty sure is currently not possible with portage,
>> however, and that I'd definitely like to see as a part of this idea is a
>> way of setting thresholds on version numbers of packages in portage such
>> that the automated upgrade system will only upgrade a package
>> automatically if the difference in version numbers between the installed
>> package and the newest available package in portage is greater than some
>> admin-tunable amount.  For example, I might not want to upgrade emacs or
>> xemacs just because a new -r number becomes available.  Maybe I don't
>> want to have such a big package upgraded automatically unless there is a
>> new major or minor version number.
>>
>> Thanks again to all the developers who have made Gentoo.  It's a really
>> terrific distro.
>
> Jakub meant the portage-devel mailing list, not this one.

woops.  when i saw portage/devel i figured one or the other... guess not...

>
> Anyway, most of this can be done already using /etc/portage files and
> some well-written cron scripts.  You can lock down versions of specific
> packages quite easily using your own package.mask and package.unmask
> files, along with package.keywords.

Yes, and as I wrote, I'm aware of your points here, and I do use these
capabilities fairly extensively now, but it is not the sort of
fine-tunable system that I have in mind where I could inform the
automated-update-system (for lack of a better name) of my wishes in
terms of which packages are safe (in my judgment, as the sysadmin of
that particular box) to upgrade in an unattended manner and which are
not (at least, not unless I'm much less well-informed on Gentoo than I
believe myself to be, which I'm not denying might be true).

And unless I'm way off-base, the version-difference-threshold notion
described above is not implemented in portage now.  Someone please
correct me if I'm wrong.

>  However, one thing you can *never*
> do is assume that *any* package that has *any* kind of configuration
> files or is a library will *never* change in an incompatible way.

Well your comment is certainly true in the most extreme interpretation,
but the same thing can be accurately said about whether or not one
should assume that the sun is going to rise tomorrow or that the
universe won't disappear in a quantum fluctuation while you're sleeping,
but IMO, such extreme statements have little value in day-to-day
application.  Everyone must make some assumptions about nearly
everything or it becomes nearly impossible to function.  I make all
kinds of assumptions in administering computers and they almost always
make my life much, MUCH easier than it would be without the assumptions.
 Sometimes they bite me, but only rarely.  The key to success here is
having the judgment to know what is relatively safe to make assumptions
about and what is not.  Judgment is something that only a human can
provide... not a computer.  This is why I want greater and more granular
control over upgrading packages in Gentoo.  Aside from the points you
make above (and I may be missing some other features currently present
in Gentoo), my choices now are, in the grossest terms: upgrade every
package by hand, one at a time, while sitting in front of the computer
(which is very close to what I spent last weekend doing) or do an emerge
world and hope for the best.  IMO, that's not much control and does not
allow for the application of judgment except in the former option (which
is very, very time consuming).

>
> Basically, what you want is the assurances of a binary distribution that
> things will "just work" when upgraded,

No.  Not true at all.  And for that matter, binary distributions (in my
10+ years of experience with them) simply do NOT just work: not for
Slackware, not for Yellowdog, not for SuSE, not for Redhat, nor
Mandrake, nor any of a dozen others I've tried.  I found that quite the
opposite was true which was one of the reasons I switched to Gentoo
(which I've found, usually DOES just work after upgrades; not always,
but usually---and this is a credit to the Gentoo developers).

What I really want is to make the process of maintaining Gentoo boxes
over the long term easier (IOW: less time-consuming) than is now true,
by adding some functionality that AFAICT does not now exist which would
allow me to automate some things, turn off automation of other things,
and as the sysadmin, have control over what those things should be.  In
my mind at least, the central theme in Gentoo of choice dovetails nicely
with what I'm trying to describe here: control and choice that is highly
fine-tunable by the owner of the box in regards to package upgrades.

I'm not a member of the portage-devel mailing list so I'm going to drop
this now.  If someone here is a member of both, then please feel free to
cross-post this thread to whatever forum is most appropriate for it.
After spending 30-45 minutes trying to help improve Gentoo by posting a
new (AFAICT) idea in bugzilla and again here, I feel like I've done
enough.  IMHO, this is an idea that would add great value to Gentoo and
I can't help but think that many sysadmins who must maintain many boxes
would agree, but I have no particular attachment to the idea that would
make me want to go around every mailing list under the sun trumpeting my
idea to anyone who will listen.  I'm just posting an idea that seemed
like a good one to me.  The devs may take it or leave it as they see fit.

Regards,
Kevin
-- 
gentoo-dev@g.o mailing list