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@gentoo.org mailing list
