Re: [gentoo-user] emerge --update behavior

[Alan McKinnon]

On Mon, 2 Jan 2012 11:20:19 -0500
Michael Mol <mikemol@×××××.com> wrote:

> On Mon, Jan 2, 2012 at 11:16 AM, Michael Mol <mikemol@×××××.com>
> wrote:
> > On Mon, Jan 2, 2012 at 11:09 AM, Michael Orlitzky
> > <michael@××××××××.com> 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 :-)



-- 
Alan McKinnnon
alan.mckinnon@×××××.com