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

[Michael Mol]

On Mon, Jan 2, 2012 at 6:33 PM, Alan McKinnon <alan.mckinnon@×××××.com> wrote:
> 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 :-)

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