Re: [gentoo-dev] Re: Wishlist: an automated package upgrade system with fine-tunable sysadmin control
On 4/27/06, Kevin [EMAIL PROTECTED] wrote: If I explore this idea with any further discussion, I'll be sure to follow the suggestions here about another list and reading past messages on that list. Feel free to look at http://dev.gentoo.org/~radek/portki/ Short feature lists: * designed to run in fully automated way * uses master/slave portage replication mode with separate _own_ master portage repo * additional own repos for home made software * allows different upgrade cycles per machine (weekly/monthly/yearly, glsa only) * allows automatic cfg upgrade _if_ file was not touched by human. * does all necessary cleaning * extensive logging * does revdep-rebuild and other necessary portage tricks * allows central configuration (useflags, make.conf etc.) * it used binpkg in early version but I discarded this idea because of: .. problems generated even on compatibile hosts .. necessity to have all the same cfg (which is often not the case) .. small gain (on todays servers compilation is fast) .. much harder individual changes to the machines * its just an integration work (mostly bash and python) around standard gentoo tools, although its in highly automated state. * easy to extend Biggest drawbacks: * some bugs :) * lacking documentation -- radoslaw. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Wishlist: an automated package upgrade system with fine-tunable sysadmin control
Richard Fish posted [EMAIL PROTECTED], excerpted below, on Wed, 26 Apr 2006 22:10:27 -0700: So maybe this could be satisified by allowing user-defined categories of packages beyond system and world? Something like world, system, fragile, non-fragile? Actually, that's called set support, and it's actively planned for a future portage. I haven't been tracking it to the point where I know what the implementation status is, but it's very likely in portage-core (aka savior aka portage-ng, portage folks correct me if I'm simply confused) to some extent now. Again, portage-devel would be the preferred place for discussions. (As used to be common courtesy with groups/lists, reading up on the last few weeks to 3 months worth of existing messages before posting something that will then be understood to be a FAQ, is nice, but the devs don't usually bite too hard if you don't. =8^) I think you could probably implement something like this yourself with a bit of trickery with the /var/lib/portage/world list. You could copy world to non-fragile, remove anything that you consider fragile from it, and then do an automatic update with: cp /var/lib/portage/world /var/lib/portage/world.bak cp /var/lib/portage/non-fragile /var/lib/portage/world emerge -DNuv world cp /var/lib/portage/world.bak /var/lib/portage/world A similar script for the fragile packages would let you update those as a group, obviously using the -p and/or --ask options as you like. Actually, the idea is slightly more complicated at one step, and slightly less at another, but very workable with existing portage. You can't simply begin with the world file, as that by definition won't necessarily include stuff in system. Rather, begin with the world file, then add the stuff in system. (The best way is probably to walk your profile tree following the parent nodes, and include what you find in packages.) Or, start generate the initial list with an emerge --pretend --emptytree newpkglist Note that the latter, however, will include trunk and branch packages as well as the leaf packages normally found in world. This would therefore require the use of --oneshot with any emerge based on the list, so as to prevent stuffing world with unnecessary dependencies. Those dependencies can also change over time, one of the reasons you /don't/ want them in world (and why an occasional emerge --depclean --pretend is recommended as routine system hygiene on a Gentoo system, generating a list to either be added to world or unmerged as necessary, read the docs for more information if you aren't already doing this as part of your normal routine). Due to this change over time, if you use this generation method, you'll also wish to regenerate the list periodically. OTOH, it'll give you a more accurate list to start with, if you consider any of the dependencies especially fragile or robust, since they'd not be directly handled using the first generation method, only treated as dependencies. In any case, once you get your list and weed out the stuff you /don't/ want on it, rather than doing that copy trickery, try this: emerge -NuDv $(cat /path/to/listfile) Again, the usual pretend/ask situation applies, and --oneshot should be added since you are updating specific packages from the command line. Also consider the effect of the -D and -N flags, as depending on your exact needs, --newuse and --deep may or may not be suitable. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Wishlist: an automated package upgrade system with fine-tunable sysadmin control
On 4/27/06, Duncan [EMAIL PROTECTED] wrote: In any case, once you get your list and weed out the stuff you /don't/ want on it, rather than doing that copy trickery, try this: Yeah, much smarter than my cp tricks. Although using emerge to generate the package list will have a problem in that it contains the versions, which is not what you want for this. But we seem to have going completely off-topic for -dev now... -Richard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Wishlist: an automated package upgrade system with fine-tunable sysadmin control
Thank you both for your detailed replies. I've got quite a list of additional notions now for trying to implement this idea myself, and I'm very grateful for the thoughtful suggestions. I also have a better understanding of current portage capabilities, so I appreciate the additional commentary on that. If I explore this idea with any further discussion, I'll be sure to follow the suggestions here about another list and reading past messages on that list. -Kevin -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Wishlist: an automated package upgrade system with fine-tunable sysadmin control
On Wed, 26 Apr 2006 15:30:35 -0400, Kevin wrote:
Jean-Francois Gagnon Laporte wrote:
On 4/26/06, Kevin [EMAIL PROTECTED] wrote:
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.
Have a look at GLCU (http://www.panhorst.com/glcu/). Might not be the
perfect solution for your needs but it might help. Tools like this
one, /etc/portage and a private overlay for testing and/or pinning
would be pretty usefull for you right now. Might want to check GLEP 19
IIRC for the enterprise tree idea.
Thanks very kindly for your reply and pointer, Jean-Francois!
-Kevin
PMFJI. It seems you want the best of both worlds, and as such are asking a
lot! I fully understand your desire, but IMHO, you can come very close,
but never achieve your stated goal. FWIW, here's what I do.
I have a daily cron job which simply does:
emerge -puNDvt --nospinner world /home/${MAILTO}/emerge.log
Then, if there is something I don't want to emerge, or a trivial -r?
revision to an ebuild I don't want, I mask it. For example, recently, gcc
went from 3.4.5 to 3.4.5-r1. To me, the change was unnecessary. So I
masked it. There are ways, as previously noted to mask to the major or
minor version, or exclude revisions as well. The problem with that
approach is that a particular revision _COULD_ be important or useful to
you. However, when I do a package.mask entry, I normally use = and mask a
specific version. Using = is dicey since you would miss an upgrade.
However, from the way I use gentoo, having an automated system would be
quite counterintuitive. Semi-automated? Sure thing. In any event, still
beats the $#^%@ out of RPMs!
Good luck.
--
Peter
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Wishlist: an automated package upgrade system with fine-tunable sysadmin control
Thanks for your informative reply, Peter. I think I'll try your method for awhile. I'm sure it's less time consuming than my current method, if perhaps still not ideal, and although I do realize this idea may be an unattainable utopia, by Jean-Francois pointing me to glcu, I'm glad to see that I'm not the only person who would like to see an improvement in this area, and that someone's already been working on it for awhile now. This motivates me to take a look at Michael's code and see if I can help make it still better. And although in my perception the thread speaks for itself, I'd like to apologize to anyone who perceived any of my comments as condescending, for that was not my intent. Perception is an interesting thing in that it depends very heavily on the one doing the perceiving and the author/speaker cannot know everything about all of the possible readers (thus all the possible perceptions/interpretations). I did my best to be clear and to the point and not intentionally condescending, using examples to elaborate, and I did not deliberately misunderstand anything. Above all else, I wish to make it clear that IMO, after fiddling with many different Linux distros for more than 10 years, the Gentoo developers have got the closest that I've seen to reaching that utopia. Very nice work, folks, and thank you very much for making such a terrific distro. -Kevin -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Wishlist: an automated package upgrade system with fine-tunable sysadmin control
Chris Gianelloni posted [EMAIL PROTECTED], excerpted below, on Wed, 26 Apr 2006 15:27:38 -0400: I'm sorry, but do your friends call you Duncan? I'll leave it at that. Who, me? looks around No, safe to say, /not/ me. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- gentoo-dev@gentoo.org mailing list
