On Mon, Jan 2, 2012 at 6:33 PM, Alan McKinnon <[email protected]> wrote: > On Mon, 2 Jan 2012 11:20:19 -0500 > Michael Mol <[email protected]> wrote: > >> On Mon, Jan 2, 2012 at 11:16 AM, Michael Mol <[email protected]> >> wrote: >> > On Mon, Jan 2, 2012 at 11:09 AM, Michael Orlitzky >> > <[email protected]> wrote: >> >> On 01/02/2012 11:01 AM, Mark Knecht wrote: >> >>> >> >>> >> >>> I tell by knowing which files I want in @world. Everything in >> >>> world should be a package __I__ specifically want to use. >> >>> Everything in world (on my machines anyway) is something: >> >>> >> >>> 1) I'd call from the command line >> >>> 2) Need to write a little software myself, most specifically a >> >>> library 3) Aid in displaying things, like font packages >> >>> 4) Something required by Gentoo that I don't totally understand, >> >>> like a virtual package. >> >>> >> >>> I just look through every so often and make sure everything seems >> >>> to meet those sorts of requirements. When I find a library or >> >>> something else then: >> >>> >> >>> 1) I make sure I'm clean with emerge -DuN @world AND emerge -p >> >>> --depclean 2) I'll delete the questionable item >> >>> 3) I'll see what happens with the two commands in #1 >> >>> >> >>> To me it's pretty straight forward, but I'm also not bothered at >> >>> all by the idea that emerge package and emerge -u package do the >> >>> same thing. A machine that doesn't have a package, when updated, >> >>> should have the package and it should (IMO) be in world, but >> >>> that's just me. >> >> >> >> >> >> Fine for your home PC, doesn't cut it on servers. I have the >> >> following in one of my world files: >> >> >> >> dev-php/PEAR-Mail >> >> dev-php/PEAR-Mail_Mime >> >> dev-php/PEAR-PEAR >> >> dev-php/PEAR-Structures_Graph >> >> >> >> which of those do I want? At least one of them was installed to >> >> support a customer's custom PHP application. Maybe all of them >> >> were and they all belong in world. No one knows, this server is >> >> older than the current --update behavior. >> >> >> >> So which ones can I remove? >> >> >> >> Solutions involving time travel and/or losing customers will be >> >> disqualified. >> > >> > Make a backup copy of your world file. >> > >> > 1a. Remove those four lines. >> > 2a. emerge -p --depclean >> > 3a. Did any of those show up in the to-be-removed set? Add them >> > back. >> > >> > Alternately: >> > 1b. emerge -pev --tree --with-bdeps=y @world >> > 2b Find those packages in the output. The tree form of the display >> > will help you see if anything is depending on them. >> > 3b. If anything is depending on them, you should be able to safely >> > remove them from your world file. I'd follow up with the 1a, 2a, 3a >> > solution to be sure. >> >> It just occurred to me...in the future, you might be able to build >> ebuilds for managing customer requests, to ensure that dependencies on >> particular packages with USE flags and version requirements are met. >> >> I haven't built ebuilds myself yet, but it's on my TODO list. >> > > It's quite easy actually, doubly so if the package follows some sane > rational build process (like eg configure && make && make install). In > that case the ebuild is very small as the portage framework does all > the heavy lifting automagically. > > I'd move that TODO item higher up on the priority list if I were you, > you'll be glad you did :-)
Oh, I know. There's a bunch of things I want to add or fix. Even if that means taking some degree of ownership of them. -- :wq
