[gentoo-user] emerge --update behavior

[gentoo-user] emerge --update behavior

[Michael Orlitzky]

Using "emerge --update foo" adds "foo" to your world file. This is 
responsible for pretty much every package that incorrectly found its way 
into one of my world files.

Is there any reason to desire the current behavior? I'd like to suggest 
that it be fixed, but want to be sure I'm not just being short-sighted.

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

[Michael Mol]

On Sun, Jan 1, 2012 at 4:50 PM, Michael Orlitzky <michael@orlitzky.com> wrote:
> Using "emerge --update foo" adds "foo" to your world file. This is
> responsible for pretty much every package that incorrectly found its way
> into one of my world files.
>
> Is there any reason to desire the current behavior? I'd like to suggest that
> it be fixed, but want to be sure I'm not just being short-sighted.

Pretty sure that's what -1 is for. I'm just getting the hang of it myself.


-- 
:wq

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

[Dale]

Michael Orlitzky wrote:
> Using "emerge --update foo" adds "foo" to your world file. This is 
> responsible for pretty much every package that incorrectly found its 
> way into one of my world files.
>
> Is there any reason to desire the current behavior? I'd like to 
> suggest that it be fixed, but want to be sure I'm not just being 
> short-sighted.
>
>

We noticed that a while back too.  I added --oneshot to my make.conf 
setting to prevent this.  When you want something added to the world 
file, check into the --select option.  I'm pretty sure that is the one.

I do agree that updates shouldn't add things to the world file but I 
wouldn't hold my breath on it getting changed.

Dale

:-)  :-)

-- 
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!

Miss the compile output?  Hint:
EMERGE_DEFAULT_OPTS="--quiet-build=n"

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

[Michael Orlitzky]

On 01/01/2012 05:06 PM, Michael Mol wrote:
> On Sun, Jan 1, 2012 at 4:50 PM, Michael Orlitzky<michael@orlitzky.com>  wrote:
>> Using "emerge --update foo" adds "foo" to your world file. This is
>> responsible for pretty much every package that incorrectly found its way
>> into one of my world files.
>>
>> Is there any reason to desire the current behavior? I'd like to suggest that
>> it be fixed, but want to be sure I'm not just being short-sighted.
>
> Pretty sure that's what -1 is for. I'm just getting the hang of it myself.
>
>

Well, I know what I'm *supposed* to do. My complaint is basically that I 
sometimes forget to add -1 with -u, and that bad things happen as a result.

But why should I have to add -1 along with it? Is there any reason you 
would ever want -u to add a package to your world file? If not, we can 
avoid headaches in the future by making it do the sane (not harmful) thing.

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

[Dale]

Michael Orlitzky wrote:
> On 01/01/2012 05:06 PM, Michael Mol wrote:
>> On Sun, Jan 1, 2012 at 4:50 PM, Michael 
>> Orlitzky<michael@orlitzky.com>  wrote:
>>> Using "emerge --update foo" adds "foo" to your world file. This is
>>> responsible for pretty much every package that incorrectly found its 
>>> way
>>> into one of my world files.
>>>
>>> Is there any reason to desire the current behavior? I'd like to 
>>> suggest that
>>> it be fixed, but want to be sure I'm not just being short-sighted.
>>
>> Pretty sure that's what -1 is for. I'm just getting the hang of it 
>> myself.
>>
>>
>
> Well, I know what I'm *supposed* to do. My complaint is basically that 
> I sometimes forget to add -1 with -u, and that bad things happen as a 
> result.
>
> But why should I have to add -1 along with it? Is there any reason you 
> would ever want -u to add a package to your world file? If not, we can 
> avoid headaches in the future by making it do the sane (not harmful) 
> thing.
>
>

Using -u used to work the way you describe but that was a while ago.  
The only thing I know of is to add --oneshot to make.conf so you don't 
forget.  I think they knew this was going to be a issue.  This is in man 
emerge:

--select [ y | n ]
Add specified packages to the world set (inverse of --oneshot). This is 
useful if you want to use  EMERGE_DEFAULT_OPTS  to  make  --oneshot 
behavior default.

The way I read that is that they expect you to add --oneshot to 
make.conf.  Like you, this makes no sense to me.  I would rather they 
leave it the way it was and then not needed the --select option at all.  :/

Then again, they add confusion so we can fix it in make.conf.  lol

Dale

:-)  :-)

-- 
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!

Miss the compile output?  Hint:
EMERGE_DEFAULT_OPTS="--quiet-build=n"

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

[Mark Knecht]

On Sun, Jan 1, 2012 at 2:31 PM, Dale <rdalek1967@gmail.com> wrote:
> Michael Orlitzky wrote:
>>
>> On 01/01/2012 05:06 PM, Michael Mol wrote:
>>>
>>> On Sun, Jan 1, 2012 at 4:50 PM, Michael Orlitzky<michael@orlitzky.com>
>>>  wrote:
>>>>
>>>> Using "emerge --update foo" adds "foo" to your world file. This is
>>>> responsible for pretty much every package that incorrectly found its way
>>>> into one of my world files.
>>>>
>>>> Is there any reason to desire the current behavior? I'd like to suggest
>>>> that
>>>> it be fixed, but want to be sure I'm not just being short-sighted.
>>>
>>>
>>> Pretty sure that's what -1 is for. I'm just getting the hang of it
>>> myself.
>>>
>>>
>>
>> Well, I know what I'm *supposed* to do. My complaint is basically that I
>> sometimes forget to add -1 with -u, and that bad things happen as a result.
>>
>> But why should I have to add -1 along with it? Is there any reason you
>> would ever want -u to add a package to your world file? If not, we can avoid
>> headaches in the future by making it do the sane (not harmful) thing.
>>
>>
>
> Using -u used to work the way you describe but that was a while ago.  The
> only thing I know of is to add --oneshot to make.conf so you don't forget.
>  I think they knew this was going to be a issue.  This is in man emerge:
>
> --select [ y | n ]
> Add specified packages to the world set (inverse of --oneshot). This is
> useful if you want to use  EMERGE_DEFAULT_OPTS  to  make  --oneshot behavior
> default.
>
> The way I read that is that they expect you to add --oneshot to make.conf.
>  Like you, this makes no sense to me.  I would rather they leave it the way
> it was and then not needed the --select option at all.  :/
>
> Then again, they add confusion so we can fix it in make.conf.  lol
>
>
> Dale
>
> :-)  :-)
>
> --
> I am only responsible for what I said ... Not for what you understood or how
> you interpreted my words!
>
> Miss the compile output?  Hint:
> EMERGE_DEFAULT_OPTS="--quiet-build=n"
>
>

I'm not clear. Why does one ever bother with emerge -u package? In 10
years of Gentoo I've managed to get by with basically either emerge
package to add something or emerge -DuN @world to stay updated. (or
@system in the old days but no longer...)

Not picking on anyone but in my mind emerge -u package _should_ add
the package to the world file because any time I run emerge with a
package name and without -1 I'm telling it to make it part of @world.
If it's not part of @world, and is already on the machine, then emerge
-DuN @world is the right way to get it and everything else updated.

Just curious...

- Mark

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

[Dale]

Mark Knecht wrote:
> On Sun, Jan 1, 2012 at 2:31 PM, Dale<rdalek1967@gmail.com>  wrote:
>> Michael Orlitzky wrote:
>>> On 01/01/2012 05:06 PM, Michael Mol wrote:
>>>> On Sun, Jan 1, 2012 at 4:50 PM, Michael Orlitzky<michael@orlitzky.com>
>>>>   wrote:
>>>>> Using "emerge --update foo" adds "foo" to your world file. This is
>>>>> responsible for pretty much every package that incorrectly found its way
>>>>> into one of my world files.
>>>>>
>>>>> Is there any reason to desire the current behavior? I'd like to suggest
>>>>> that
>>>>> it be fixed, but want to be sure I'm not just being short-sighted.
>>>>
>>>> Pretty sure that's what -1 is for. I'm just getting the hang of it
>>>> myself.
>>>>
>>>>
>>> Well, I know what I'm *supposed* to do. My complaint is basically that I
>>> sometimes forget to add -1 with -u, and that bad things happen as a result.
>>>
>>> But why should I have to add -1 along with it? Is there any reason you
>>> would ever want -u to add a package to your world file? If not, we can avoid
>>> headaches in the future by making it do the sane (not harmful) thing.
>>>
>>>
>> Using -u used to work the way you describe but that was a while ago.  The
>> only thing I know of is to add --oneshot to make.conf so you don't forget.
>>   I think they knew this was going to be a issue.  This is in man emerge:
>>
>> --select [ y | n ]
>> Add specified packages to the world set (inverse of --oneshot). This is
>> useful if you want to use  EMERGE_DEFAULT_OPTS  to  make  --oneshot behavior
>> default.
>>
>> The way I read that is that they expect you to add --oneshot to make.conf.
>>   Like you, this makes no sense to me.  I would rather they leave it the way
>> it was and then not needed the --select option at all.  :/
>>
>> Then again, they add confusion so we can fix it in make.conf.  lol
>>
>>
>> Dale
>>
>> :-)  :-)
>>
>> --
>> I am only responsible for what I said ... Not for what you understood or how
>> you interpreted my words!
>>
>> Miss the compile output?  Hint:
>> EMERGE_DEFAULT_OPTS="--quiet-build=n"
>>
>>
> I'm not clear. Why does one ever bother with emerge -u package? In 10
> years of Gentoo I've managed to get by with basically either emerge
> package to add something or emerge -DuN @world to stay updated. (or
> @system in the old days but no longer...)
>
> Not picking on anyone but in my mind emerge -u package _should_ add
> the package to the world file because any time I run emerge with a
> package name and without -1 I'm telling it to make it part of @world.
> If it's not part of @world, and is already on the machine, then emerge
> -DuN @world is the right way to get it and everything else updated.
>
> Just curious...
>
> - Mark
>
>


Sometimes I do my updates one package at a time.  I would then use the 
-u option so that it would be updated, not added to world.  To me, 
update means update.  If there is no option then it should be installed 
and added to world.  That is how it was done for a good long while then 
got changed.

Dale

:-)  :-)

-- 
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!

Miss the compile output?  Hint:
EMERGE_DEFAULT_OPTS="--quiet-build=n"

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

[Claudio Roberto França Pereira]

Actually, -u doesn't mean update, means filter packages that are not
updatable (are already the most recent version).
It's a filter option, not an action. Portage doesn't work with actions.

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

[Dale]

Claudio Roberto França Pereira wrote:
> Actually, -u doesn't mean update, means filter packages that are not
> updatable (are already the most recent version).
> It's a filter option, not an action. Portage doesn't work with actions.
>
>

Not according to the man page:

        --update (-u)
               Updates packages to the best version available, which may 
not always be the  highest version number due to masking for testing and 
develop‐
               ment.  Package  atoms  specified on the command line are 
greedy, meaning that unspecific atoms may match multiple versions of 
slotted pack‐
               ages.

It is a command line, or make.conf, option but it tells emerge what to 
do.  It's no different than -D or -N.  They are all options but they 
tell portage what you want it to do.  Update means update.  That's why 
it is called update instead of something else.

Dale

:-)  :-)

-- 
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!

Miss the compile output?  Hint:
EMERGE_DEFAULT_OPTS="--quiet-build=n"

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

[Michael Orlitzky]

On 01/01/2012 05:54 PM, Claudio Roberto França Pereira wrote:
> Actually, -u doesn't mean update, means filter packages that are not
> updatable (are already the most recent version).
> It's a filter option, not an action. Portage doesn't work with actions.
>

I can see that this view is logically consistent, however,

   --update (-u)
     Updates packages to the best version available,  which  may  not
     always be the  highest version number due to masking for testing
     and development. Package atoms specified on the command line are
     greedy,  meaning  that  unspecific atoms may match multiple ver‐
     sions of slotted packages.

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

[Michael Orlitzky]

On 01/01/2012 05:40 PM, Mark Knecht wrote:
>
> I'm not clear. Why does one ever bother with emerge -u package? In 10
> years of Gentoo I've managed to get by with basically either emerge
> package to add something or emerge -DuN @world to stay updated. (or
> @system in the old days but no longer...)

Usually it's because a world update wants to do both trivial version 
bumps and replace major software at the same time. I can't take a server 
down for an hour in the middle of the day to update Apache, but I can 
bump timezone-data, sure.

Even when there aren't any major packages, sometimes I'll do the smaller 
ones in chunks, so that if something breaks I don't have to revert 300 
packages.


> Not picking on anyone but in my mind emerge -u package _should_ add
> the package to the world file because any time I run emerge with a
> package name and without -1 I'm telling it to make it part of @world.
> If it's not part of @world, and is already on the machine, then emerge
> -DuN @world is the right way to get it and everything else updated.

No offense taken, that's why I asked. I can almost never get away with a 
full world update except on my personal machines, so the way --update 
works is important to me.

Adding unwanted packages to world is especially bad because there are 
things like amavisd-new that have undeclared (optional?) dependencies on 
miscellaneous perl packages. After a few months, I don't remember which 
perl packages I wanted vs. which ones portage stuck in there by 
accident, so the world file just grows and grows.

Adding --oneshot to the default opts is probably the way to go when I'm 
ready to concede that I'll forget -1 occasionally. It feels dirty, though.

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

[Mark Knecht]

On Sun, Jan 1, 2012 at 3:07 PM, Michael Orlitzky <michael@orlitzky.com> wrote:
> On 01/01/2012 05:40 PM, Mark Knecht wrote:
>>
>>
>> I'm not clear. Why does one ever bother with emerge -u package? In 10
>> years of Gentoo I've managed to get by with basically either emerge
>> package to add something or emerge -DuN @world to stay updated. (or
>> @system in the old days but no longer...)
>
>
> Usually it's because a world update wants to do both trivial version bumps
> and replace major software at the same time. I can't take a server down for
> an hour in the middle of the day to update Apache, but I can bump
> timezone-data, sure.
>
> Even when there aren't any major packages, sometimes I'll do the smaller
> ones in chunks, so that if something breaks I don't have to revert 300
> packages.
>
>
>
>> Not picking on anyone but in my mind emerge -u package _should_ add
>> the package to the world file because any time I run emerge with a
>> package name and without -1 I'm telling it to make it part of @world.
>> If it's not part of @world, and is already on the machine, then emerge
>> -DuN @world is the right way to get it and everything else updated.
>
>
> No offense taken, that's why I asked. I can almost never get away with a
> full world update except on my personal machines, so the way --update works
> is important to me.
>
> Adding unwanted packages to world is especially bad because there are things
> like amavisd-new that have undeclared (optional?) dependencies on
> miscellaneous perl packages. After a few months, I don't remember which perl
> packages I wanted vs. which ones portage stuck in there by accident, so the
> world file just grows and grows.
>
> Adding --oneshot to the default opts is probably the way to go when I'm
> ready to concede that I'll forget -1 occasionally. It feels dirty, though.
>

OK, makes sense to me.

1) I only do home machines. My family all over California now runs
Gentoo and has for years. Windows no longer exists anywhere except in
VMs. Clearly I can see why someone running production machines
wouldn't want to do that.

2) I forget the -1 sometimes when I do an individual package update.
However I generally remember to go back and hand edit the world file
once a quarter or so and remove anything that isn't a real
application, etc.

Glad I wasn't sounding too negative. It wasn't my intention.

Cheers,
Mark

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

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 475 bytes --]

On Sun, 01 Jan 2012 18:07:45 -0500, Michael Orlitzky wrote:

> Usually it's because a world update wants to do both trivial version 
> bumps and replace major software at the same time. I can't take a
> server down for an hour in the middle of the day to update Apache, but
> I can bump timezone-data, sure.

Why would you need to take it down? All you need to do is restart Apache
after the update.


-- 
Neil Bothwick

I distinctly remember forgetting that.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Michael Orlitzky]

On 01/01/2012 07:09 PM, Neil Bothwick wrote:
> On Sun, 01 Jan 2012 18:07:45 -0500, Michael Orlitzky wrote:
>
>> Usually it's because a world update wants to do both trivial version
>> bumps and replace major software at the same time. I can't take a
>> server down for an hour in the middle of the day to update Apache, but
>> I can bump timezone-data, sure.
>
> Why would you need to take it down? All you need to do is restart Apache
> after the update.
>

I have to test, like, 200 websites to make sure they still work. 
Something /always/ breaks.

Apache was just an example. PHP is the same way: functions get removed, 
renamed, or just subtly changed. I can't replace Dovecot with users 
logged in. I can't upgrade/restart postgresql while clients are hitting 
it. If I'm working remotely, I don't want to update openvpn, iptables, 
or even openssh. There's a long list of packages that I just ain't gonna 
mess with during the day.

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

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 893 bytes --]

On Sun, 01 Jan 2012 19:24:35 -0500, Michael Orlitzky wrote:

> > Why would you need to take it down? All you need to do is restart
> > Apache after the update.
> >  
> 
> I have to test, like, 200 websites to make sure they still work. 
> Something /always/ breaks.
> 
> Apache was just an example. PHP is the same way: functions get removed, 
> renamed, or just subtly changed. I can't replace Dovecot with users 
> logged in. I can't upgrade/restart postgresql while clients are hitting 
> it. If I'm working remotely, I don't want to update openvpn, iptables, 
> or even openssh. There's a long list of packages that I just ain't
> gonna mess with during the day.

And you test all this on production servers?


-- 
Neil Bothwick

A friend of mine sent me a postcard with a satellite photo of the
entire planet on it, and on the back he wrote, "Wish you were here."

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Alan McKinnon]

On Sun, 01 Jan 2012 16:12:34 -0600
Dale <rdalek1967@gmail.com> wrote:

> Michael Orlitzky wrote:
> > Using "emerge --update foo" adds "foo" to your world file. This is 
> > responsible for pretty much every package that incorrectly found
> > its way into one of my world files.
> >
> > Is there any reason to desire the current behavior? I'd like to 
> > suggest that it be fixed, but want to be sure I'm not just being 
> > short-sighted.
> >
> >
> 
> We noticed that a while back too.  I added --oneshot to my make.conf 
> setting to prevent this.  When you want something added to the world 
> file, check into the --select option.  I'm pretty sure that is the
> one.
> 
> I do agree that updates shouldn't add things to the world file but I 
> wouldn't hold my breath on it getting changed.


The current behaviour is the correct and expected one - you told
portage to emerge something and it did. Why else would you emerge
something if you didn't intend it to become a permanent feature of the
system and part of world? This has always been the definition of emerge
- to make it permanent.

If you want to emerge something and NOT have portage put it in world
then you must use the -1 option. Remember that emerging something is
supposed to be a permanent action that you (as root) intended to
happen. If what you intend is something more unusual like a mere test
or "just to see what would happen" then you must take additional steps
(to make it clear that you are doing something out of the ordinary).

It's the same logic as rm uses:

the user told the computer to delete a file so the computer did what it
was told by it's master and deleted the file. What else would you
expect it to do? 


p.s. before I forget: Happy New Year :-)



-- 
Alan McKinnnon
alan.mckinnon@gmail.com

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

[Alan McKinnon]

On Sun, 01 Jan 2012 19:24:35 -0500
Michael Orlitzky <michael@orlitzky.com> wrote:

> On 01/01/2012 07:09 PM, Neil Bothwick wrote:
> > On Sun, 01 Jan 2012 18:07:45 -0500, Michael Orlitzky wrote:
> >
> >> Usually it's because a world update wants to do both trivial
> >> version bumps and replace major software at the same time. I can't
> >> take a server down for an hour in the middle of the day to update
> >> Apache, but I can bump timezone-data, sure.
> >
> > Why would you need to take it down? All you need to do is restart
> > Apache after the update.
> >
> 
> I have to test, like, 200 websites to make sure they still work. 
> Something /always/ breaks.
> 
> Apache was just an example. PHP is the same way: functions get
> removed, renamed, or just subtly changed. I can't replace Dovecot
> with users logged in. I can't upgrade/restart postgresql while
> clients are hitting it. If I'm working remotely, I don't want to
> update openvpn, iptables, or even openssh. There's a long list of
> packages that I just ain't gonna mess with during the day.
 

You have a production machine delivering valuable services to multiple
users.

Therefore you must only update *anything* on it during planned
maintenance slots. If paying customers are involved then preferably
with a second redundant parallel machine to take over the load during
that slot. You don't have much of an option about this in the real
world, think of it as a constraint that you must simply deal with. 

Or think about it another way, if the machine was running RHEL, you
wouldn't just blindly run yum update in the middle of the working day
and expect it to all be just fine.


-- 
Alan McKinnnon
alan.mckinnon@gmail.com

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

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 2234 bytes --]

On Monday 02 Jan 2012 10:06:39 Alan McKinnon wrote:
> On Sun, 01 Jan 2012 19:24:35 -0500
> 
> Michael Orlitzky <michael@orlitzky.com> wrote:
> > On 01/01/2012 07:09 PM, Neil Bothwick wrote:
> > > On Sun, 01 Jan 2012 18:07:45 -0500, Michael Orlitzky wrote:
> > >> Usually it's because a world update wants to do both trivial
> > >> version bumps and replace major software at the same time. I can't
> > >> take a server down for an hour in the middle of the day to update
> > >> Apache, but I can bump timezone-data, sure.
> > > 
> > > Why would you need to take it down? All you need to do is restart
> > > Apache after the update.
> > 
> > I have to test, like, 200 websites to make sure they still work.
> > Something /always/ breaks.
> > 
> > Apache was just an example. PHP is the same way: functions get
> > removed, renamed, or just subtly changed. I can't replace Dovecot
> > with users logged in. I can't upgrade/restart postgresql while
> > clients are hitting it. If I'm working remotely, I don't want to
> > update openvpn, iptables, or even openssh. There's a long list of
> > packages that I just ain't gonna mess with during the day.
> 
> You have a production machine delivering valuable services to multiple
> users.
> 
> Therefore you must only update *anything* on it during planned
> maintenance slots. If paying customers are involved then preferably
> with a second redundant parallel machine to take over the load during
> that slot. You don't have much of an option about this in the real
> world, think of it as a constraint that you must simply deal with.
> 
> Or think about it another way, if the machine was running RHEL, you
> wouldn't just blindly run yum update in the middle of the working day
> and expect it to all be just fine.

+1

Even on binary distros I would be apprehensive to update/upgrade a production 
machine, unless I have run the updates on the test box first.  Even so, because 
I do not have the luxury of identical hardware some times the odd thing may 
break, but it is a very rare occurrence.  With everything running on VMs these 
days (although not yet my case) this is becoming less of a problem I would 
think.
-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Dale]

Alan McKinnon wrote:
> The current behaviour is the correct and expected one - you told 
> portage to emerge something and it did. Why else would you emerge 
> something if you didn't intend it to become a permanent feature of the 
> system and part of world? This has always been the definition of 
> emerge - to make it permanent. If you want to emerge something and NOT 
> have portage put it in world then you must use the -1 option. Remember 
> that emerging something is supposed to be a permanent action that you 
> (as root) intended to happen. If what you intend is something more 
> unusual like a mere test or "just to see what would happen" then you 
> must take additional steps (to make it clear that you are doing 
> something out of the ordinary). It's the same logic as rm uses: the 
> user told the computer to delete a file so the computer did what it 
> was told by it's master and deleted the file. What else would you 
> expect it to do? p.s. before I forget: Happy New Year :-) 

I didn't tell it to add it to the world file tho, I just told it to 
update it hence the option --update.  I update things all the time but 
it doesn't mean I want them added to the world file.  If I want to 
emerge something and have it added to the world file, I leave the -u 
option out of it, then it should be added because I requested it to be 
emerged not updated.

Example:

emerge phonon

That means I want it emerged on my system and should be added to the 
world file.

emerge -u phonon

That means I want to update/upgrade phonon.  I don't want it in my world 
file, just updated.  This is the way it worked before --oneshot came 
along.  It is not the way it is now but it was that way a good while back.

Happy New Year to you too.  Mine are getting better.  I lost my Dad on 
New Years Day many years ago.  It's not the same since.

Dale

:-)  :-)

-- 
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!

Miss the compile output?  Hint:
EMERGE_DEFAULT_OPTS="--quiet-build=n"

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

[Alan McKinnon]

On Mon, 02 Jan 2012 04:19:39 -0600
Dale <rdalek1967@gmail.com> wrote:

> Alan McKinnon wrote:
> > The current behaviour is the correct and expected one - you told 
> > portage to emerge something and it did. Why else would you emerge 
> > something if you didn't intend it to become a permanent feature of
> > the system and part of world? This has always been the definition
> > of emerge - to make it permanent. If you want to emerge something
> > and NOT have portage put it in world then you must use the -1
> > option. Remember that emerging something is supposed to be a
> > permanent action that you (as root) intended to happen. If what you
> > intend is something more unusual like a mere test or "just to see
> > what would happen" then you must take additional steps (to make it
> > clear that you are doing something out of the ordinary). It's the
> > same logic as rm uses: the user told the computer to delete a file
> > so the computer did what it was told by it's master and deleted the
> > file. What else would you expect it to do? p.s. before I forget:
> > Happy New Year :-) 
> 
> I didn't tell it to add it to the world file tho, I just told it to 
> update it hence the option --update.  I update things all the time
> but it doesn't mean I want them added to the world file.  If I want
> to emerge something and have it added to the world file, I leave the
> -u option out of it, then it should be added because I requested it
> to be emerged not updated.
> 
> Example:
> 
> emerge phonon
> 
> That means I want it emerged on my system and should be added to the 
> world file.
> 
> emerge -u phonon
> 
> That means I want to update/upgrade phonon.  I don't want it in my
> world file, just updated.  This is the way it worked before --oneshot
> came along.  It is not the way it is now but it was that way a good
> while back.
> 
> Happy New Year to you too.  Mine are getting better.  I lost my Dad
> on New Years Day many years ago.  It's not the same since.


The current behaviour seems more logical to me. You also seem to have
gotten used to the old way and can't see past it :-)

When Zac needs to define when something does, he needs to keep the big
picture in mind to get consistency. So what's the purpose of emerge?
Well, read the DESCRIPTION in the man page:

=====
DESCRIPTION
       emerge  is  the  definitive  command-line interface to the
Portage system.  It is primarily used for installing packages, and
emerge can automatically handle any dependencies that the desired
package has.  emerge can also update the portage tree, making new and
updated packages available.  emerge gracefully handles updating
installed packages to newer  releases  as well.  It handles both source
and binary packages, and it can be used to create binary packages for
distribution.
=====

Obviously it must maintain system and the world file to do this. That
is the primary function, everything else is secondary. When emerge
merges something to the live system, it puts everything listed on the
command line into world; everything brought along automagically as
a dep does not go into world. Any changes to that purpose must have a
very good reason.

Emergeing something puts it in world, we have established that. But
this thing called an "update" does not imply that the packages are not
to go in world - an update is just an update, not "merge this but also
do something weird with world". Actually --update makes little sense
with just individual packages, if they are not already installed they
will be (which is exactly what you get by omitting --update). It does
make a lot of sense when used with system, world, and sets though.

So it seems to me Zac has removed a peculiar bahaviour and made it much
more consistent:

When you emerge packages explicitly by name, they go into world always.
The only way to do it differently is to use -1 which tells portage to
not put them in world.

Makes sense to me.

-- 
Alan McKinnnon
alan.mckinnon@gmail.com

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

[Dale]

Alan McKinnon wrote:
> On Mon, 02 Jan 2012 04:19:39 -0600
> Dale<rdalek1967@gmail.com>  wrote:
>
>> Alan McKinnon wrote:
>>> The current behaviour is the correct and expected one - you told
>>> portage to emerge something and it did. Why else would you emerge
>>> something if you didn't intend it to become a permanent feature of
>>> the system and part of world? This has always been the definition
>>> of emerge - to make it permanent. If you want to emerge something
>>> and NOT have portage put it in world then you must use the -1
>>> option. Remember that emerging something is supposed to be a
>>> permanent action that you (as root) intended to happen. If what you
>>> intend is something more unusual like a mere test or "just to see
>>> what would happen" then you must take additional steps (to make it
>>> clear that you are doing something out of the ordinary). It's the
>>> same logic as rm uses: the user told the computer to delete a file
>>> so the computer did what it was told by it's master and deleted the
>>> file. What else would you expect it to do? p.s. before I forget:
>>> Happy New Year :-)
>> I didn't tell it to add it to the world file tho, I just told it to
>> update it hence the option --update.  I update things all the time
>> but it doesn't mean I want them added to the world file.  If I want
>> to emerge something and have it added to the world file, I leave the
>> -u option out of it, then it should be added because I requested it
>> to be emerged not updated.
>>
>> Example:
>>
>> emerge phonon
>>
>> That means I want it emerged on my system and should be added to the
>> world file.
>>
>> emerge -u phonon
>>
>> That means I want to update/upgrade phonon.  I don't want it in my
>> world file, just updated.  This is the way it worked before --oneshot
>> came along.  It is not the way it is now but it was that way a good
>> while back.
>>
>> Happy New Year to you too.  Mine are getting better.  I lost my Dad
>> on New Years Day many years ago.  It's not the same since.
>
> The current behaviour seems more logical to me. You also seem to have
> gotten used to the old way and can't see past it :-)
>
> When Zac needs to define when something does, he needs to keep the big
> picture in mind to get consistency. So what's the purpose of emerge?
> Well, read the DESCRIPTION in the man page:
>
> =====
> DESCRIPTION
>         emerge  is  the  definitive  command-line interface to the
> Portage system.  It is primarily used for installing packages, and
> emerge can automatically handle any dependencies that the desired
> package has.  emerge can also update the portage tree, making new and
> updated packages available.  emerge gracefully handles updating
> installed packages to newer  releases  as well.  It handles both source
> and binary packages, and it can be used to create binary packages for
> distribution.
> =====
>
> Obviously it must maintain system and the world file to do this. That
> is the primary function, everything else is secondary. When emerge
> merges something to the live system, it puts everything listed on the
> command line into world; everything brought along automagically as
> a dep does not go into world. Any changes to that purpose must have a
> very good reason.
>
> Emergeing something puts it in world, we have established that. But
> this thing called an "update" does not imply that the packages are not
> to go in world - an update is just an update, not "merge this but also
> do something weird with world". Actually --update makes little sense
> with just individual packages, if they are not already installed they
> will be (which is exactly what you get by omitting --update). It does
> make a lot of sense when used with system, world, and sets though.
>
> So it seems to me Zac has removed a peculiar bahaviour and made it much
> more consistent:
>
> When you emerge packages explicitly by name, they go into world always.
> The only way to do it differently is to use -1 which tells portage to
> not put them in world.
>
> Makes sense to me.
>

That's why I fixed the new way to be closer to what I am used to.  I 
added --oneshot to my make.conf.  When I really need to add something to 
world, I just use --select y -nav.  To me, that is a lot of extra steps 
to be "consistent".  That works if it is already installed.  For those 
reading, leave off the -n if it is a fresh new install of a package.  
The -n means to not compile it, just add it to world.

You see my dracut post?  I *think* I got init thingy to work.  O_O  It 
took me a couple months but . . . .

Dale

:-)  :-)

-- 
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!

Miss the compile output?  Hint:
EMERGE_DEFAULT_OPTS="--quiet-build=n"

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

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 798 bytes --]

On Mon, 02 Jan 2012 05:06:32 -0600, Dale wrote:

> That's why I fixed the new way to be closer to what I am used to.  I 
> added --oneshot to my make.conf.  When I really need to add something
> to world, I just use --select y -nav.  To me, that is a lot of extra
> steps to be "consistent".

You are trying to be "consistent" with your memory of how things used
to work (which is flawed, oneshot has been around a lot longer than you
think). Zac is looking for self-consistency.

Unfortunately, this is one of those cases where there is no overriding
argument in favour of one way or the other, prejudice and inertia play
more of a part than logic for most people.


-- 
Neil Bothwick

Whats the difference between a magician and a brothel?
One has a cunning array of stunts,

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Michael Orlitzky]

On 01/02/2012 05:06 AM, Alan McKinnon wrote:
>
> You have a production machine delivering valuable services to multiple
> users.
>
> Therefore you must only update *anything* on it during planned
> maintenance slots. If paying customers are involved then preferably
> with a second redundant parallel machine to take over the load during
> that slot. You don't have much of an option about this in the real
> world, think of it as a constraint that you must simply deal with.

In a perfect world, we would do this for all updates. But there's only 
one of me, and my time is better spent doing other things than,

   * writing documentation
   * updating the test machine to match production
   * doing the update
   * testing all critical services
   * pushing the update live
   * retesting

just to update ca-certificates on a database server.

We do all of the above for major upgrades, and by now I have a pretty 
good idea of which upgrades are going to break something.

I still wind up using emerge -u on the test machines -- I upgrade all of 
the minor packages and ensure that things are still working before I do 
the major one, so if something breaks, I'm not chasing ghosts.

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

[Michael Orlitzky]

On 01/02/2012 08:36 AM, Neil Bothwick wrote:
> On Mon, 02 Jan 2012 05:06:32 -0600, Dale wrote:
>
>> That's why I fixed the new way to be closer to what I am used to.  I
>> added --oneshot to my make.conf.  When I really need to add something
>> to world, I just use --select y -nav.  To me, that is a lot of extra
>> steps to be "consistent".
>
> You are trying to be "consistent" with your memory of how things used
> to work (which is flawed, oneshot has been around a lot longer than you
> think). Zac is looking for self-consistency.
>
> Unfortunately, this is one of those cases where there is no overriding
> argument in favour of one way or the other, prejudice and inertia play
> more of a part than logic for most people.

Sure there is: adding a package to the world file can screw up your 
system if it's unintentional.

*Not* adding the package to world when you do an update is *not* 
harmful, because,

   * Nobody would use --update to install a new package
   * Depclean can show you that you made a mistake

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

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 829 bytes --]

On Mon, 02 Jan 2012 08:50:36 -0500, Michael Orlitzky wrote:

>    * Nobody would use --update to install a new package

Actually, that's a good reason to use --update on a single package, as
it installs a new package, but does not reinstall an existing package,
so you can emerge -u a list of packages and only install the new ones.

However, you can now do that with -n, which does add to world, so this
can also be used as an argument for -u to not touch world. I'm leaning
towards the view that I would prefer world to be untouched, but, as I
said, there's no compelling argument one way or the other.
 
Maybe you can file a bug report that gets enough votes to persuade Zac to
add a configuration option for this, or write the patch yourself.


-- 
Neil Bothwick

Do radioactive cats have 18 half-lives?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Michael Mol]

Neil Bothwick wrote:
> On Mon, 02 Jan 2012 08:50:36 -0500, Michael Orlitzky wrote:
>
>>     * Nobody would use --update to install a new package
>
> Actually, that's a good reason to use --update on a single package, as
> it installs a new package, but does not reinstall an existing package,
> so you can emerge -u a list of packages and only install the new ones.
>
> However, you can now do that with -n, which does add to world, so this
> can also be used as an argument for -u to not touch world. I'm leaning
> towards the view that I would prefer world to be untouched, but, as I
> said, there's no compelling argument one way or the other.
>
> Maybe you can file a bug report that gets enough votes to persuade Zac to
> add a configuration option for this, or write the patch yourself.

Personally, I'd *really* prefer not to have package manager semantics 
switch out from under me.

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

[Alan McKinnon]

On Mon, 02 Jan 2012 08:50:36 -0500
Michael Orlitzky <michael@orlitzky.com> wrote:

> On 01/02/2012 08:36 AM, Neil Bothwick wrote:
> > On Mon, 02 Jan 2012 05:06:32 -0600, Dale wrote:
> >
> >> That's why I fixed the new way to be closer to what I am used to.
> >> I added --oneshot to my make.conf.  When I really need to add
> >> something to world, I just use --select y -nav.  To me, that is a
> >> lot of extra steps to be "consistent".
> >
> > You are trying to be "consistent" with your memory of how things
> > used to work (which is flawed, oneshot has been around a lot longer
> > than you think). Zac is looking for self-consistency.
> >
> > Unfortunately, this is one of those cases where there is no
> > overriding argument in favour of one way or the other, prejudice
> > and inertia play more of a part than logic for most people.
> 
> Sure there is: adding a package to the world file can screw up your 
> system if it's unintentional.
> 
> *Not* adding the package to world when you do an update is *not* 
> harmful, because,
> 
>    * Nobody would use --update to install a new package
>    * Depclean can show you that you made a mistake
> 

There's a deeper more fundamental assumption at work here, and it's the
targeted userbase.

Devs assume Gentoo users use Gentoo because the user wants control and
tells the computer what to do. By and large that's how it works (except
for catastrophic or unrecoverable errors like unmerging python or
portage).

So when the user tells portage to emerge (not merge) something it goes
in world as obviously that's what the user wanted. Presumably the user
knows what they are doing and can deal with both pieces. If the user
would rather have software hold his hand, that user is better served by
Windows or Ubuntu or any number of user-centric distros, but probably
not by Gentoo.

This isn't elitist, it's just the way things are. Portage's job is to
listen to *you*, not to to tell you what you want. The automation
portage provides is just the logical conclusion of what should happen
in future after you emerged something.

-- 
Alan McKinnnon
alan.mckinnon@gmail.com

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

[Michael Orlitzky]

On 01/02/2012 10:05 AM, Alan McKinnon wrote:
>
> So when the user tells portage to emerge (not merge) something it goes
> in world as obviously that's what the user wanted. Presumably the user
> knows what they are doing and can deal with both pieces. If the user
> would rather have software hold his hand, that user is better served by
> Windows or Ubuntu or any number of user-centric distros, but probably
> not by Gentoo.
>
> This isn't elitist, it's just the way things are. Portage's job is to
> listen to *you*, not to to tell you what you want. The automation
> portage provides is just the logical conclusion of what should happen
> in future after you emerged something.
>

That unspoken agreement is only beneficial if I have the means by which 
to tell portage what I want it to do. The problem lies at a higher 
level: I think I'm telling portage to update a package, but that's not 
what --update means. It's hard for me to tell portage what I want it to 
do, so the fact that it assumes I know what I'm doing isn't constructive.

I wouldn't call it elitist or blame anyone for the change; the entire 
premise for my argument is that people make mistakes. But I do think 
it's bad engineering: 50% of users are going to think it works the wrong 
way no matter which one you choose, but only one of them screws up your 
system when you get it wrong.

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

[Tanstaafl]

On 2012-01-01 5:13 PM, Michael Orlitzky <michael@orlitzky.com> wrote:
> On 01/01/2012 05:06 PM, Michael Mol wrote:
>> On Sun, Jan 1, 2012 at 4:50 PM, Michael Orlitzky<michael@orlitzky.com>
>> wrote:
>>> Using "emerge --update foo" adds "foo" to your world file. This is
>>> responsible for pretty much every package that incorrectly found its way
>>> into one of my world files.
>>>
>>> Is there any reason to desire the current behavior? I'd like to
>>> suggest that
>>> it be fixed, but want to be sure I'm not just being short-sighted.

>> Pretty sure that's what -1 is for. I'm just getting the hang of it
>> myself.

> Well, I know what I'm *supposed* to do. My complaint is basically that I
> sometimes forget to add -1 with -u, and that bad things happen as a result.
>
> But why should I have to add -1 along with it? Is there any reason you
> would ever want -u to add a package to your world file? If not, we can
> avoid headaches in the future by making it do the sane (not harmful) thing.

Uh-oh...

I've *never* used -1 unless I'm trying to fix a broken package by 
recompiling it... I've always just used

emerge -vuDN world...

Been doing it this way for 7+ years, and never had a problem, so my 
question is:

What 'harmful' thing has been happening on/to my system all these years?

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

[Tanstaafl]

On 2012-01-01 6:22 PM, Mark Knecht <markknecht@gmail.com> wrote:
> 2) I forget the -1 sometimes when I do an individual package update.
> However I generally remember to go back and hand edit the world file
> once a quarter or so and remove anything that isn't a real
> application, etc.

How do you tell which is which?

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

[Michael Orlitzky]

On 01/02/2012 10:31 AM, Tanstaafl wrote:
>
> Uh-oh...
>
> I've *never* used -1 unless I'm trying to fix a broken package by
> recompiling it... I've always just used
>
> emerge -vuDN world...
>
> Been doing it this way for 7+ years, and never had a problem, so my
> question is:
>
> What 'harmful' thing has been happening on/to my system all these years?
>

If you only update world, nothing.

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

[Michael Mol]

On Mon, Jan 2, 2012 at 10:31 AM, Tanstaafl <tanstaafl@libertytrek.org> wrote:
> On 2012-01-01 5:13 PM, Michael Orlitzky <michael@orlitzky.com> wrote:
>>
>> On 01/01/2012 05:06 PM, Michael Mol wrote:
>>>
>>> On Sun, Jan 1, 2012 at 4:50 PM, Michael Orlitzky<michael@orlitzky.com>
>>> wrote:
>>>>
>>>> Using "emerge --update foo" adds "foo" to your world file. This is
>>>> responsible for pretty much every package that incorrectly found its way
>>>> into one of my world files.
>>>>
>>>> Is there any reason to desire the current behavior? I'd like to
>>>> suggest that
>>>> it be fixed, but want to be sure I'm not just being short-sighted.
>
>
>>> Pretty sure that's what -1 is for. I'm just getting the hang of it
>>> myself.
>
>
>> Well, I know what I'm *supposed* to do. My complaint is basically that I
>> sometimes forget to add -1 with -u, and that bad things happen as a
>> result.
>>
>> But why should I have to add -1 along with it? Is there any reason you
>> would ever want -u to add a package to your world file? If not, we can
>> avoid headaches in the future by making it do the sane (not harmful)
>> thing.
>
>
> Uh-oh...
>
> I've *never* used -1 unless I'm trying to fix a broken package by
> recompiling it... I've always just used
>
> emerge -vuDN world...
>
> Been doing it this way for 7+ years, and never had a problem, so my question
> is:
>
> What 'harmful' thing has been happening on/to my system all these years?

Probably nothing, because of your use of --deep and --newuse. That's
pretty much the way I upgrade software on my system.

-- 
:wq

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

[Michael Orlitzky]

On 01/02/2012 10:35 AM, Tanstaafl wrote:
> On 2012-01-01 6:22 PM, Mark Knecht<markknecht@gmail.com>  wrote:
>> 2) I forget the -1 sometimes when I do an individual package update.
>> However I generally remember to go back and hand edit the world file
>> once a quarter or so and remove anything that isn't a real
>> application, etc.
>
> How do you tell which is which?
>

You can't =)

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

[Michael Mol]

On Mon, Jan 2, 2012 at 10:35 AM, Tanstaafl <tanstaafl@libertytrek.org> wrote:
> On 2012-01-01 6:22 PM, Mark Knecht <markknecht@gmail.com> wrote:
>>
>> 2) I forget the -1 sometimes when I do an individual package update.
>> However I generally remember to go back and hand edit the world file
>> once a quarter or so and remove anything that isn't a real
>> application, etc.
>
>
> How do you tell which is which?

I have 947 packages installed, but only 103 lines in my world file.
All of those should be files that I explicitly chose to install at one
time or another. If I don't recognize a line or I don't know what it
does, out it goes. Then I'll run a pretend depclean, see if anything I
*want* is being removed, select those packages, and try the depclean
again.

Unless you're a developer, you probably don't need most packages under
dev-libs/* or media-libs/* in your world file; any that are actually
required should be pulled in as a dependency of something else.
-- 
:wq

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

[Mark Knecht]

On Mon, Jan 2, 2012 at 7:35 AM, Tanstaafl <tanstaafl@libertytrek.org> wrote:
> On 2012-01-01 6:22 PM, Mark Knecht <markknecht@gmail.com> wrote:
>>
>> 2) I forget the -1 sometimes when I do an individual package update.
>> However I generally remember to go back and hand edit the world file
>> once a quarter or so and remove anything that isn't a real
>> application, etc.
>
>
> How do you tell which is which?
>

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.

HTH,
Mark

mark@c2stable ~ $ cat /var/lib/portage/world
app-admin/syslog-ng
app-benchmarks/bonnie++
app-benchmarks/iozone
app-cdr/cdrtools
app-cdr/dvd+rw-tools
app-editors/vim
app-emulation/virtualbox
app-emulation/virtualbox-extpack-oracle
app-emulation/vmware-player
app-forensics/chkrootkit
app-misc/screen
app-pda/gtkpod
app-pda/ifuse
app-portage/eix
app-portage/gentoolkit
app-portage/layman
app-portage/portage-utils
app-text/acroread
dev-util/nvidia-cuda-sdk
dev-util/nvidia-cuda-toolkit
dev-util/strace
dev-vcs/subversion
kde-base/kde-meta
mail-client/mailx
mail-mta/ssmtp
media-fonts/font-bitstream-100dpi
media-fonts/font-bitstream-75dpi
media-fonts/font-bitstream-speedo
media-fonts/font-bitstream-type1
media-fonts/freefont-ttf
media-fonts/freefonts
media-fonts/ttf-bitstream-vera
media-gfx/imagemagick
media-libs/exiftool
media-libs/mesa
media-sound/alsa-tools
media-sound/alsa-utils
media-video/dvdbackup
media-video/handbrake
media-video/nvidia-settings
media-video/smplayer
media-video/vobcopy
media-video/xine-ui
net-analyzer/nettop
net-dns/noip-updater
net-fs/samba
net-im/skype
net-misc/ntp
net-misc/rdesktop
net-misc/telnet-bsd
net-misc/tightvnc
net-misc/unison
net-misc/whois
sci-libs/ta-lib
sys-apps/dstat
sys-apps/hdparm
sys-apps/hwinfo
sys-apps/less
sys-apps/lshw
sys-apps/microcode-ctl
sys-apps/mlocate
sys-apps/portage
sys-apps/smartmontools
sys-boot/grub-static
sys-fs/dosfstools
sys-fs/fuse
sys-fs/mdadm
sys-kernel/gentoo-sources
sys-kernel/gentoo-sources:3.1.0-r1
sys-kernel/module-rebuild
sys-power/apcupsd
sys-power/cpufrequtils
sys-power/powertop
sys-process/iotop
sys-process/lsof
sys-process/time
sys-process/vixie-cron
virtual/jdk
virtual/jre
www-client/firefox
www-plugins/adobe-flash
www-servers/thttpd
x11-apps/mesa-progs
x11-apps/xclock
x11-apps/xhost
x11-base/xorg-drivers
x11-base/xorg-server
x11-drivers/nvidia-drivers
x11-drivers/xf86-input-evdev
x11-drivers/xf86-input-virtualbox
x11-drivers/xf86-video-fbdev
x11-drivers/xf86-video-virtualbox
x11-misc/driconf
x11-misc/read-edid
x11-misc/xsnap
mark@c2stable ~ $

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

[Michael Orlitzky]

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.

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

[Michael Mol]

On Mon, Jan 2, 2012 at 11:09 AM, Michael Orlitzky <michael@orlitzky.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.

-- 
:wq

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

[Michael Mol]

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

-- 
:wq

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

[Mark Knecht]

On Mon, Jan 2, 2012 at 8:09 AM, Michael Orlitzky <michael@orlitzky.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.
>

I'm not clear. You allow your server customers to modify your servers,
or what, they asked you to install stuff and now you don't know which
of them was needed and why? I'm just not clear.

My basic response, again allowing that I don't run servers that have
'customers' on them, is that 'equery depends' is the basic path to
determine if any of these are dependencies of other things in the
world file. If they are then they themselves possibly don't need to be
in the world file unless they meet my rule #2 as they are required for
some sort of development work your customer does.

I completely agree about travel time. My family lives 350 miles away.
I've managed their machines for 10 years this way and only once had a
problem that required me to get physical access. In the normal worst
case I have a Live CD with a couple of instructions they can execute
to get me back into the machine.

- Mark

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

[Frank Steinmetzger]

[-- Attachment #1: Type: text/plain, Size: 1761 bytes --]

On Mon, Jan 02, 2012 at 10:26:02AM -0500, Michael Orlitzky wrote:
> On 01/02/2012 10:05 AM, Alan McKinnon wrote:
> >
> > So when the user tells portage to emerge (not merge) something it goes
> > in world as obviously that's what the user wanted. Presumably the user
> > knows what they are doing and can deal with both pieces. If the user
> > would rather have software hold his hand, that user is better served by
> > Windows or Ubuntu or any number of user-centric distros, but probably
> > not by Gentoo.
> >
> > This isn't elitist, it's just the way things are. Portage's job is to
> > listen to *you*, not to to tell you what you want. The automation
> > portage provides is just the logical conclusion of what should happen
> > in future after you emerged something.
> >
> 
> That unspoken agreement is only beneficial if I have the means by which 
> to tell portage what I want it to do. The problem lies at a higher 
> level: I think I'm telling portage to update a package, but that's not 
> what --update means. It's hard for me to tell portage what I want it to 
> do, so the fact that it assumes I know what I'm doing isn't constructive.

Look at it this way:
with emerge <package> you tell portage to install a package and add it to
world. Period. The package will be installed, no matter whether it’s at the
newest version or not.  With -u, however, you tell emerge to only do the
installation if the package is actually upgradable.  So it’s not an action
(“upgrade this package”), but an option (“install only if upgradable”).
-- 
Gruß | Greetings | Qapla'
I forbid any use of my email addresses with Facebook services.

The bad thing about Wikipedia jokes is
- Deleted due to lack of relevance. -

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

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

[Michael Orlitzky]

On 01/02/2012 11:22 AM, Mark Knecht wrote:
>
> I'm not clear. You allow your server customers to modify your servers,
> or what, they asked you to install stuff and now you don't know which
> of them was needed and why? I'm just not clear.

They ask us to install stuff, and now we don't know which ones are needed.


> My basic response, again allowing that I don't run servers that have
> 'customers' on them, is that 'equery depends' is the basic path to
> determine if any of these are dependencies of other things in the
> world file. If they are then they themselves possibly don't need to be
> in the world file unless they meet my rule #2 as they are required for
> some sort of development work your customer does.
>
> I completely agree about travel time. My family lives 350 miles away.
> I've managed their machines for 10 years this way and only once had a
> problem that required me to get physical access. In the normal worst
> case I have a Live CD with a couple of instructions they can execute
> to get me back into the machine.

Well, travel time sucks too, but I was referring to time travel via e.g. 
a time machine, in case some wise guy tried to answer "well you 
shouldn't have done that." =)

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

[Michael Orlitzky]

On 01/02/2012 11:16 AM, Michael Mol wrote:
>>
>> 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.
>

Sorry, but these won't work.

Let's say that dev-php/PEAR-Mail_Mime has a dependency on 
dev-php/PEAR-Mail, but I have a customer who needs dev-php/PEAR-Mail for 
a contact form.

Following your process, I would remove dev-php/PEAR-Mail from my world 
file. If I ever remove dev-php/PEAR-Mail_Mime, depclean will remove 
PEAR-Mail and break the guy's site.

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

[Michael Orlitzky]

On 01/02/2012 11:25 AM, Frank Steinmetzger wrote:
>
> Look at it this way:
> with emerge<package>  you tell portage to install a package and add it to
> world. Period. The package will be installed, no matter whether it’s at the
> newest version or not.  With -u, however, you tell emerge to only do the
> installation if the package is actually upgradable.  So it’s not an action
> (“upgrade this package”), but an option (“install only if upgradable”).

I have no problem seeing it that way, and don't have a semantic 
preference for one or the other. My problem is that the current behavior 
can screw up your world file, whereas the old behavior could not.

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

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 519 bytes --]

On Mon, 02 Jan 2012 10:35:46 -0500, Tanstaafl wrote:

> > 2) I forget the -1 sometimes when I do an individual package update.
> > However I generally remember to go back and hand edit the world file
> > once a quarter or so and remove anything that isn't a real
> > application, etc.  
> 
> How do you tell which is which?

By running --depclean -p afterwards. If it wants to remove something you
need, add it to world with emerge -n.


-- 
Neil Bothwick

WinErr 00E: Window open - Do not look inside

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 360 bytes --]

On Mon, 02 Jan 2012 11:33:31 -0500, Michael Orlitzky wrote:

> Well, travel time sucks too, but I was referring to time travel via
> e.g. a time machine, in case some wise guy tried to answer "well you 
> shouldn't have done that." =)

Ah, you mean backups, not time travel :)


-- 
Neil Bothwick

"Mmmm, trouble with grammer have I, yes?" - Yoda

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 1437 bytes --]

On Mon, 02 Jan 2012 11:09:06 -0500, Michael Orlitzky wrote:

> 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?

I use sets to deal with this, so much simpler to organise than a single
world file. If I am installing something from outside of portage and it
has dependencies, I create a set listing those dependencies and emerge
that set. If I remove the package I can remove the set and depclean will
unmerge anything not needed by other packages.

For example, I use a perl script called zenus (specific to my ISP) and 
/etc/portage/sets/zenus-deps contains

dev-perl/SOAP-Lite
perl-gcpan/SOAP-DateTime
dev-perl/Class-Inspector
dev-perl/Data-Dumper-Concise

Those packages may or may not be needed by anything else, but a set means
I keep them installed without cluttering world. I do similar for specific
projects, especially short term ones so I can clean up after.


-- 
Neil Bothwick

Committee (noun): A group of people spending hours taking minutes

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Michael Mol]

On Mon, Jan 2, 2012 at 11:33 AM, Michael Orlitzky <michael@orlitzky.com> wrote:
> On 01/02/2012 11:16 AM, Michael Mol wrote:
>>>
>>>
>>> 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.
>>
>
> Sorry, but these won't work.
>
> Let's say that dev-php/PEAR-Mail_Mime has a dependency on dev-php/PEAR-Mail,
> but I have a customer who needs dev-php/PEAR-Mail for a contact form.
>
> Following your process, I would remove dev-php/PEAR-Mail from my world file.
> If I ever remove dev-php/PEAR-Mail_Mime, depclean will remove PEAR-Mail and
> break the guy's site.

That's the purpose of the "emerge -p" step. Presumably, you would see
that there's a package in the list that you're not comfortable with
removing, you'd decide you didn't want it removed, and you'd add it
back to your world set.

If you're not comfortable removing *any* package that's in your world
set, then, no, there's no way to tell the difference. From this point
forward, your best bet is to modify EMERGE_DEFAULT_OPTS to reflect the
safest practice for your environment. And start keeping a list of
packages installed to meet customers' requests. Portage apparently
supports your desired workflow, but it needs to be set up for it.

As to recovering from your current scenario...there might be some way
to watch your apache processes to identify which files get used over a
three-month span, from that list derive a list of which packages were
used, and from *that* list, derive a list of which packages weren't
used. (Or make an ebuild explicitly identifying the utilized
dependencies, and let depclean handle the rest)

-- 
:wq

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

[Mark Knecht]

On Mon, Jan 2, 2012 at 8:57 AM, Neil Bothwick <neil@digimed.co.uk> wrote:
> On Mon, 02 Jan 2012 10:35:46 -0500, Tanstaafl wrote:
>
>> > 2) I forget the -1 sometimes when I do an individual package update.
>> > However I generally remember to go back and hand edit the world file
>> > once a quarter or so and remove anything that isn't a real
>> > application, etc.
>>
>> How do you tell which is which?
>
> By running --depclean -p afterwards. If it wants to remove something you
> need, add it to world with emerge -n.
>
>
> --
> Neil Bothwick

That works for the case where the software is managed by portage,
which is likely 99.9999% of what's on Gentoo systems worldwide. It
doesn't work however for the odd case where I write some little
program which requires a library (ta-lib in my portage file) and I
don't write an ebuild to build it. I've never bothered to learn to do
my own ebuilds but at some level it would be a good idea, and I think
it would address Mr. Orlitsky's issue about what his users need and
why. If they are on Gentoo then they could write a simple ebuild that
did nothing but install the packages they want. That ebuild goes into
world and let's him understand why every package in on the system. In
the earlier example if all 4 files were required then this user ebuild
has 4 entries in it. They ask him to run it, he runs it, it's in
world. End of package issue I think.

It doesn't address more system'ish things like editing config file to
support those things, etc, but I don't know how that gets done unless
he grants sudo to them, etc.

Just an idea.

Cheers,
Mark

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

[Michael Orlitzky]

On 01/02/12 12:06, Michael Mol wrote:
> 
> That's the purpose of the "emerge -p" step. Presumably, you would see
> that there's a package in the list that you're not comfortable with
> removing, you'd decide you didn't want it removed, and you'd add it
> back to your world set.

Yeah, I'm not sure I can remove any of them. The only way I see to
determine what's necessary at this point is to remove it and see if
stuff breaks.


> If you're not comfortable removing *any* package that's in your world
> set, then, no, there's no way to tell the difference. From this point
> forward, your best bet is to modify EMERGE_DEFAULT_OPTS to reflect the
> safest practice for your environment. And start keeping a list of
> packages installed to meet customers' requests. Portage apparently
> supports your desired workflow, but it needs to be set up for it.
> 
> As to recovering from your current scenario...there might be some way
> to watch your apache processes to identify which files get used over a
> three-month span, from that list derive a list of which packages were
> used, and from *that* list, derive a list of which packages weren't
> used. (Or make an ebuild explicitly identifying the utilized
> dependencies, and let depclean handle the rest)

That's probably more work than copying everything to another box,
emptying the world file, and adding things back until stuff works.

Either way the current situation is "you're kinda screwed" which is why
I proposed avoiding it in the future (for others, too) by fixing --update.

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

[Michael Mol]

On Mon, Jan 2, 2012 at 12:39 PM, Michael Orlitzky <michael@orlitzky.com> wrote:
> On 01/02/12 12:06, Michael Mol wrote:
>>
>> That's the purpose of the "emerge -p" step. Presumably, you would see
>> that there's a package in the list that you're not comfortable with
>> removing, you'd decide you didn't want it removed, and you'd add it
>> back to your world set.
>
> Yeah, I'm not sure I can remove any of them. The only way I see to
> determine what's necessary at this point is to remove it and see if
> stuff breaks.
>
>
>> If you're not comfortable removing *any* package that's in your world
>> set, then, no, there's no way to tell the difference. From this point
>> forward, your best bet is to modify EMERGE_DEFAULT_OPTS to reflect the
>> safest practice for your environment. And start keeping a list of
>> packages installed to meet customers' requests. Portage apparently
>> supports your desired workflow, but it needs to be set up for it.
>>
>> As to recovering from your current scenario...there might be some way
>> to watch your apache processes to identify which files get used over a
>> three-month span, from that list derive a list of which packages were
>> used, and from *that* list, derive a list of which packages weren't
>> used. (Or make an ebuild explicitly identifying the utilized
>> dependencies, and let depclean handle the rest)
>
> That's probably more work than copying everything to another box,
> emptying the world file, and adding things back until stuff works.
>
> Either way the current situation is "you're kinda screwed" which is why
> I proposed avoiding it in the future (for others, too) by fixing --update.

I hope you don't take this as a kind of disrespect, but this really
feels more like administrator error than tool error. As someone else
remarked, it's portage's job to do what you tell it to do; you point
the gun, pull the trigger, it delivers the projectile.

The biggest bug I can see in this whole mess is that the man page
might stand some editing for clarity.

-- 
:wq

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

[Mark Knecht]

On Mon, Jan 2, 2012 at 9:39 AM, Michael Orlitzky <michael@orlitzky.com> wrote:
> On 01/02/12 12:06, Michael Mol wrote:
>>
>> That's the purpose of the "emerge -p" step. Presumably, you would see
>> that there's a package in the list that you're not comfortable with
>> removing, you'd decide you didn't want it removed, and you'd add it
>> back to your world set.
>
> Yeah, I'm not sure I can remove any of them. The only way I see to
> determine what's necessary at this point is to remove it and see if
> stuff breaks.
>

Again, 'equery depends' will tell you if any package locatable through
the @world hierarchy needs the package. No need to uninstall anything
to do that level of investigation. revdep-rebuild -I is also useful,
although more historically than now.

>
>> If you're not comfortable removing *any* package that's in your world
>> set, then, no, there's no way to tell the difference. From this point
>> forward, your best bet is to modify EMERGE_DEFAULT_OPTS to reflect the
>> safest practice for your environment. And start keeping a list of
>> packages installed to meet customers' requests. Portage apparently
>> supports your desired workflow, but it needs to be set up for it.
>>
>> As to recovering from your current scenario...there might be some way
>> to watch your apache processes to identify which files get used over a
>> three-month span, from that list derive a list of which packages were
>> used, and from *that* list, derive a list of which packages weren't
>> used. (Or make an ebuild explicitly identifying the utilized
>> dependencies, and let depclean handle the rest)
>
> That's probably more work than copying everything to another box,
> emptying the world file, and adding things back until stuff works.
>
> Either way the current situation is "you're kinda screwed" which is why
> I proposed avoiding it in the future (for others, too) by fixing --update.
>

Really, the proposal to 'fix --update' doesn't address really knowing
what your system is running and why. Get to the root of that and the
--update thing becomes the non-issue that many of us think it is.

- Mark

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

[Michael Orlitzky]

On 01/02/12 12:29, Mark Knecht wrote:
> 
> That works for the case where the software is managed by portage,
> which is likely 99.9999% of what's on Gentoo systems worldwide. It
> doesn't work however for the odd case where I write some little
> program which requires a library (ta-lib in my portage file) and I
> don't write an ebuild to build it. I've never bothered to learn to do
> my own ebuilds but at some level it would be a good idea, and I think
> it would address Mr. Orlitsky's issue about what his users need and
> why. If they are on Gentoo then they could write a simple ebuild that
> did nothing but install the packages they want. That ebuild goes into
> world and let's him understand why every package in on the system. In
> the earlier example if all 4 files were required then this user ebuild
> has 4 entries in it. They ask him to run it, he runs it, it's in
> world. End of package issue I think.
> 
> It doesn't address more system'ish things like editing config file to
> support those things, etc, but I don't know how that gets done unless
> he grants sudo to them, etc.

I have started writing ebuilds for my own sanity, but it doesn't
actually fix the problem. Unless you have perfect discipline and always
use --oneshot along with --update, you still don't actually know
anything about the packages in your world file!

Another example: I have a custom ebuild to install the dependencies for
www-apps/movable-type-5.02. One of its dependencies is dev-perl/DBD-mysql.

If I have both www-apps/movable-type-5.02 and dev-perl/DBD-mysql in my
world file, can I remove the latter? Who knows. Maybe I added it on
purpose because I need it, and maybe I forgot --oneshot while updating it.

There's no way to tell, and the existence of the ebuild doesn't preclude
--oneshot mistakes.

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

[Michael Orlitzky]

On 01/02/12 12:45, Michael Mol wrote:
> 
> I hope you don't take this as a kind of disrespect, but this really
> feels more like administrator error than tool error. As someone else
> remarked, it's portage's job to do what you tell it to do; you point
> the gun, pull the trigger, it delivers the projectile.
> 

I don't -- I've admitted this was user error a number of times.

Old behavior: user error has no consequences.
New behavior: user error permanently breaks your world file.

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

[Michael Mol]

On Mon, Jan 2, 2012 at 12:47 PM, Mark Knecht <markknecht@gmail.com> wrote:
> On Mon, Jan 2, 2012 at 9:39 AM, Michael Orlitzky <michael@orlitzky.com> wrote:
>> On 01/02/12 12:06, Michael Mol wrote:
>>>
>>> That's the purpose of the "emerge -p" step. Presumably, you would see
>>> that there's a package in the list that you're not comfortable with
>>> removing, you'd decide you didn't want it removed, and you'd add it
>>> back to your world set.
>>
>> Yeah, I'm not sure I can remove any of them. The only way I see to
>> determine what's necessary at this point is to remove it and see if
>> stuff breaks.
>>
>
> Again, 'equery depends' will tell you if any package locatable through
> the @world hierarchy needs the package. No need to uninstall anything
> to do that level of investigation. revdep-rebuild -I is also useful,
> although more historically than now.

The problem is that he won't know which atoms in his current world set
are necessarily depended upon by other packages vs the ones which are
requested by his customers' request. (Portage knows nothing about his
customers' requests; it only knows he installed packages at one point
or another.)

[snip]


-- 
:wq

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

[Michael Orlitzky]

On 01/02/12 12:47, Mark Knecht wrote:
> 
> Again, 'equery depends' will tell you if any package locatable through
> the @world hierarchy needs the package. No need to uninstall anything
> to do that level of investigation. revdep-rebuild -I is also useful,
> although more historically than now.
> 

This was essentially Michal Mol's suggestion, and I gave an example
where it would remove something important.


> Really, the proposal to 'fix --update' doesn't address really knowing
> what your system is running and why. Get to the root of that and the
> --update thing becomes the non-issue that many of us think it is.
>

This would be a suggestion to travel back in time and document something
that I have no way of knowing now.

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

[Michael Mol]

On Mon, Jan 2, 2012 at 12:55 PM, Michael Orlitzky <michael@orlitzky.com> wrote:
> On 01/02/12 12:45, Michael Mol wrote:
>>
>> I hope you don't take this as a kind of disrespect, but this really
>> feels more like administrator error than tool error. As someone else
>> remarked, it's portage's job to do what you tell it to do; you point
>> the gun, pull the trigger, it delivers the projectile.
>>
>
> I don't -- I've admitted this was user error a number of times.
>
> Old behavior: user error has no consequences.
> New behavior: user error permanently breaks your world file.

I missed where this was new behavior. Being that this will be the 56th
message in this thread, though, I'm not particularly inclined to go
back and hunt for it. >.>

-- 
:wq

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

[Graham Murray]

Tanstaafl <tanstaafl@libertytrek.org> writes:

> On 2012-01-01 6:22 PM, Mark Knecht <markknecht@gmail.com> wrote:
>> 2) I forget the -1 sometimes when I do an individual package update.
>> However I generally remember to go back and hand edit the world file
>> once a quarter or so and remove anything that isn't a real
>> application, etc.
>
> How do you tell which is which?

There is a package app-portage/udep which used to do this. However it is
masked and marked as not working with current portage facilities (such
as EAPI), so is almost certainly not safe to use. It would be good if
this could be updated to handle current portage.

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

[Michael Orlitzky]

On 01/02/12 13:07, Michael Mol wrote:
> On Mon, Jan 2, 2012 at 12:55 PM, Michael Orlitzky <michael@orlitzky.com> wrote:
>> On 01/02/12 12:45, Michael Mol wrote:
>>>
>>> I hope you don't take this as a kind of disrespect, but this really
>>> feels more like administrator error than tool error. As someone else
>>> remarked, it's portage's job to do what you tell it to do; you point
>>> the gun, pull the trigger, it delivers the projectile.
>>>
>>
>> I don't -- I've admitted this was user error a number of times.
>>
>> Old behavior: user error has no consequences.
>> New behavior: user error permanently breaks your world file.
> 
> I missed where this was new behavior. Being that this will be the 56th
> message in this thread, though, I'm not particularly inclined to go
> back and hunt for it. >.>
> 

It used to work the way I want it to, for years. That's partly why I
can't remember to add --oneshot to emerge -uN.

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

[Dale]

Michael Orlitzky wrote:
> On 01/02/2012 11:25 AM, Frank Steinmetzger wrote:
>>
>> Look at it this way:
>> with emerge<package>  you tell portage to install a package and add 
>> it to
>> world. Period. The package will be installed, no matter whether it’s 
>> at the
>> newest version or not.  With -u, however, you tell emerge to only do the
>> installation if the package is actually upgradable.  So it’s not an 
>> action
>> (“upgrade this package”), but an option (“install only if upgradable”).
>
> I have no problem seeing it that way, and don't have a semantic 
> preference for one or the other. My problem is that the current 
> behavior can screw up your world file, whereas the old behavior could 
> not.
>
>

Plus the only way to fix this is to override it in make.conf with the 
--oneshot option.  To me, when you have to fix something like this, 
something is not done right.

I like the way Frank explained this.  That was my point way back.

Dale

:-)  :-)

-- 
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!

Miss the compile output?  Hint:
EMERGE_DEFAULT_OPTS="--quiet-build=n"

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

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 864 bytes --]

On Mon, 2 Jan 2012 09:29:57 -0800, Mark Knecht wrote:

> That works for the case where the software is managed by portage,
> which is likely 99.9999% of what's on Gentoo systems worldwide. It
> doesn't work however for the odd case where I write some little
> program which requires a library (ta-lib in my portage file) and I
> don't write an ebuild to build it. I've never bothered to learn to do
> my own ebuilds but at some level it would be a good idea, and I think
> it would address Mr. Orlitsky's issue about what his users need and
> why.

That's more easily handled with sets. No ebuild writing skills are needed
and there's no danger of atoms being accidentally added to the set.


-- 
Neil Bothwick

*Libra*: /(Sept 23--Oct 23)/ An unfortunate typo on your application
results in your being accepted into the Legion Of Superherpes.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 522 bytes --]

On Mon, 02 Jan 2012 12:55:19 -0500, Michael Orlitzky wrote:

> New behavior: user error permanently breaks your world file.

It is not permanently broken, that implies it would stop the system
working. It is merely damaged, and repairable. It may take a little
effort to repair, but that will help you remember to be more careful in
future.


-- 
Neil Bothwick

"I can picture in my mind a world without war, a world without hate. And I
can picture us attacking that world, because they'd never expect it."

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Michael Orlitzky]

On 01/02/2012 03:50 PM, Neil Bothwick wrote:
> On Mon, 02 Jan 2012 12:55:19 -0500, Michael Orlitzky wrote:
>
>> New behavior: user error permanently breaks your world file.
>
> It is not permanently broken, that implies it would stop the system
> working. It is merely damaged, and repairable. It may take a little
> effort to repair, but that will help you remember to be more careful in
> future.
>

No one has offered up a way to fix it yet, or a downside to the old 
behavior.

Making your software punish its users isn't going to make them more 
careful, it's going to make them stop using your software. If bash did 
an 'rm -rf /' when you mistyped a command[1], would you think, gee, I 
need to be more careful? Or would you think the guy who made it do that 
was an asshole?


[1] There is distro that does this, even though it's an extreme example.

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

[Alan McKinnon]

On Mon, 02 Jan 2012 11:33:43 -0500
Michael Orlitzky <michael@orlitzky.com> wrote:

> On 01/02/2012 11:16 AM, Michael Mol wrote:
> >>
> >> 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.
> >
> 
> Sorry, but these won't work.
> 
> Let's say that dev-php/PEAR-Mail_Mime has a dependency on 
> dev-php/PEAR-Mail, but I have a customer who needs dev-php/PEAR-Mail
> for a contact form.
> 
> Following your process, I would remove dev-php/PEAR-Mail from my
> world file. If I ever remove dev-php/PEAR-Mail_Mime, depclean will
> remove PEAR-Mail and break the guy's site.
> 
cocktail
Neil's suggestion of sets sounds like what you want here. Unfortunately
it only works smoothly on first emerge (later on you have to dig
through dep graphs to find the full dep list):

First run emerge -p to find all the packages that will be pulled in,
and add the whole lot to a set with a clear name that indicates it's
function. Then emerge that set. As you discover further deps you can
manually add them to the set

It's quite a lot of extra work and you have to remember to do it, but
it has the benefit of being somewhat self-documenting, at least in
terms of having a record of what set pulled a package in initially.

-- 
Alan McKinnnon
alan.mckinnon@gmail.com

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

[Michael Orlitzky]

On 01/02/2012 04:11 PM, Alan McKinnon wrote:
> cocktail
> Neil's suggestion of sets sounds like what you want here. Unfortunately
> it only works smoothly on first emerge (later on you have to dig
> through dep graphs to find the full dep list):
>
> First run emerge -p to find all the packages that will be pulled in,
> and add the whole lot to a set with a clear name that indicates it's
> function. Then emerge that set. As you discover further deps you can
> manually add them to the set
>
> It's quite a lot of extra work and you have to remember to do it, but
> it has the benefit of being somewhat self-documenting, at least in
> terms of having a record of what set pulled a package in initially.
>

Requires time travel, not a solution!

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

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 718 bytes --]

On Mon, 2 Jan 2012 23:11:03 +0200, Alan McKinnon wrote:

> Neil's suggestion of sets sounds like what you want here. Unfortunately
> it only works smoothly on first emerge (later on you have to dig
> through dep graphs to find the full dep list):
> 

As it is only used to support non-portage installs, there isn't that much
work involved, usually only looking at the README, adding the relevant
packages to a set and emerging the set. Unless the out-of-tree packages
dependencies change, there's no real maintenance to do, unless portage
goes and upgrades a dep to a newer and incompatible version.


-- 
Neil Bothwick

If bankers can count, how come they have eight windows and only four
tellers?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 913 bytes --]

On Mon, 02 Jan 2012 16:08:44 -0500, Michael Orlitzky wrote:

> > It is not permanently broken, that implies it would stop the system
> > working. It is merely damaged, and repairable. It may take a little
> > effort to repair, but that will help you remember to be more careful
> > in future.

> No one has offered up a way to fix it yet, or a downside to the old 
> behavior.

Yes they have. Remove anything in the least suspect and emerge -cp. Then
emerge -n anything listed that you need.

There was a script floating around that created a new world file that
contained all installed packages that were not a dependency of another
installed package. It's not a perfect fix, but pretty close.

Found it: http://forums.gentoo.org/viewtopic-p-6861484.html


-- 
Neil Bothwick

The law of Probability Dispersal decrees that whatever it is that hits
the fan will not be evenly distributed.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 364 bytes --]

On Mon, 02 Jan 2012 16:18:23 -0500, Michael Orlitzky wrote:

> Requires time travel, not a solution!

Fine. Stick with your broken system and ignore any suggestions to either
repair the damage you have already done or to avoid future damage. Blame
it all on the portage devs and demand a refund!


-- 
Neil Bothwick

Fragile. Do not turn umop ap1sdn!

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Michael Orlitzky]

On 01/02/2012 04:25 PM, Neil Bothwick wrote:
> On Mon, 02 Jan 2012 16:08:44 -0500, Michael Orlitzky wrote:
>
>> No one has offered up a way to fix it yet, or a downside to the old
>> behavior.
>
> Yes they have. Remove anything in the least suspect and emerge -cp. Then
> emerge -n anything listed that you need.

I don't know which ones I need, and I can't just remove them and cross 
my fingers, because these are live servers.


> There was a script floating around that created a new world file that
> contained all installed packages that were not a dependency of another
> installed package. It's not a perfect fix, but pretty close.

I gave a concrete example from one of our web servers where this would 
remove something important.

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

[Michael Mol]

On Mon, Jan 2, 2012 at 4:18 PM, Michael Orlitzky <michael@orlitzky.com> wrote:
> On 01/02/2012 04:11 PM, Alan McKinnon wrote:
>>
>> cocktail
>> Neil's suggestion of sets sounds like what you want here. Unfortunately
>> it only works smoothly on first emerge (later on you have to dig
>> through dep graphs to find the full dep list):
>>
>> First run emerge -p to find all the packages that will be pulled in,
>> and add the whole lot to a set with a clear name that indicates it's
>> function. Then emerge that set. As you discover further deps you can
>> manually add them to the set
>>
>> It's quite a lot of extra work and you have to remember to do it, but
>> it has the benefit of being somewhat self-documenting, at least in
>> terms of having a record of what set pulled a package in initially.
>>
>
> Requires time travel, not a solution!

Seriously. Do you want a solution, or do you just want to rant about a
change to the behavior of --update?

Without some existing log of the things your existing customers
specifically need, and without some means to intuit what they need by
the web apps they've uploaded to their accounts, there isn't going to
be any solution that isn't going to involve either a risk of breakage
to your existing clients' sites, preservation of your damaged world
file as an "assume this is what I need" set, or a great deal of work
coming up with the list of things you actually need.

Without that request log, you're in a *recovery* scenario, and there
is no quick fix. All solutions offered that aren't time travel (better
termed, "change your practices so this doesn't happen again"), are
going to require a lot of effort and legwork on your part, and will
*all* carry risk.

Here's another time travel solution, but this one doesn't require
changing past actions: Go through your log files and look for
'Updating world file", and look at what portage was doing at the time.
Go through your emails with your customers and identify which packages
they requested. Look at your own public-facing website and look at the
list of packages you promise.

If you either have all your emerge logs, or all your customer contact
logs, it's doable.

-- 
:wq

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

[Michael Orlitzky]

On 01/02/2012 04:28 PM, Neil Bothwick wrote:
> On Mon, 02 Jan 2012 16:18:23 -0500, Michael Orlitzky wrote:
>
>> Requires time travel, not a solution!
>
> Fine. Stick with your broken system and ignore any suggestions to either
> repair the damage you have already done or to avoid future damage. Blame
> it all on the portage devs and demand a refund!

I'm not blaming anyone, and the portage devs don't personally owe me 
anything. I see an opportunity to make portage safer for all Gentoo 
users, and am trying to make my case here, don't take it personally.

I appreciate the suggestions, but I already know how to avoid the 
problem in the future. But, if ever you make a single mistake, those 
solutions go out the window because you can no longer say what in the 
world file is important.

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

[Michael Orlitzky]

On 01/02/2012 04:34 PM, Michael Mol wrote:
> On Mon, Jan 2, 2012 at 4:18 PM, Michael Orlitzky<michael@orlitzky.com>  wrote:
>> On 01/02/2012 04:11 PM, Alan McKinnon wrote:
>>>
>>> cocktail
>>> Neil's suggestion of sets sounds like what you want here. Unfortunately
>>> it only works smoothly on first emerge (later on you have to dig
>>> through dep graphs to find the full dep list):
>>>
>>> First run emerge -p to find all the packages that will be pulled in,
>>> and add the whole lot to a set with a clear name that indicates it's
>>> function. Then emerge that set. As you discover further deps you can
>>> manually add them to the set
>>>
>>> It's quite a lot of extra work and you have to remember to do it, but
>>> it has the benefit of being somewhat self-documenting, at least in
>>> terms of having a record of what set pulled a package in initially.
>>>
>>
>> Requires time travel, not a solution!
>
> Seriously. Do you want a solution, or do you just want to rant about a
> change to the behavior of --update?
>

All I originally wanted to know was if anyone had a real reason to 
prefer the current behavior over the old.

I've shown that there's a problem with the current behavior; if there 
are no real problems with the old behavior, then it's worth raising the 
issue.

I know how to avoid the problem in the future, but there are plenty of 
other Gentoo users who don't, and who also won't be able to fix today's 
mistakes a year from now.

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

[Michael Mol]

On Mon, Jan 2, 2012 at 4:48 PM, Michael Orlitzky <michael@orlitzky.com> wrote:
> On 01/02/2012 04:34 PM, Michael Mol wrote:
>>
>> On Mon, Jan 2, 2012 at 4:18 PM, Michael Orlitzky<michael@orlitzky.com>
>>  wrote:
>>>
>>> On 01/02/2012 04:11 PM, Alan McKinnon wrote:
>>>>
>>>>
>>>> cocktail
>>>> Neil's suggestion of sets sounds like what you want here. Unfortunately
>>>> it only works smoothly on first emerge (later on you have to dig
>>>> through dep graphs to find the full dep list):
>>>>
>>>> First run emerge -p to find all the packages that will be pulled in,
>>>> and add the whole lot to a set with a clear name that indicates it's
>>>> function. Then emerge that set. As you discover further deps you can
>>>> manually add them to the set
>>>>
>>>> It's quite a lot of extra work and you have to remember to do it, but
>>>> it has the benefit of being somewhat self-documenting, at least in
>>>> terms of having a record of what set pulled a package in initially.
>>>>
>>>
>>> Requires time travel, not a solution!
>>
>>
>> Seriously. Do you want a solution, or do you just want to rant about a
>> change to the behavior of --update?
>>
>
> All I originally wanted to know was if anyone had a real reason to prefer
> the current behavior over the old.

Ah. I must have gotten confused at "So which ones can I remove?
Solutions involving time travel and/or losing customers will be
disqualified."

>
> I've shown that there's a problem with the current behavior; if there are no
> real problems with the old behavior, then it's worth raising the issue.

Ah. Then based on the conversation thus far, it sounds like you'd have
to ask the developer who made the change.

>
> I know how to avoid the problem in the future, but there are plenty of other
> Gentoo users who don't, and who also won't be able to fix today's mistakes a
> year from now.

-- 
:wq

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

[Michael Orlitzky]

On 01/02/2012 04:58 PM, Michael Mol wrote:
>
> Ah. I must have gotten confused at "So which ones can I remove?
> Solutions involving time travel and/or losing customers will be
> disqualified."
>

Sorry, this thread has gotten a little out of hand =)

I think my point was: most solutions available to me now involve 
potential breakage. Others require me to be more careful 6 years ago. 
Neither of those is desirable.

The current --update behavior makes this situation easy to get into. If 
there are no downsides to the old behavior (the point of this thread), 
then I think the old behavior is preferable.

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

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 1011 bytes --]

On Mon, 02 Jan 2012 16:33:04 -0500, Michael Orlitzky wrote:

> > Yes they have. Remove anything in the least suspect and emerge -cp.
> > Then emerge -n anything listed that you need.  
> 
> I don't know which ones I need, and I can't just remove them and cross 
> my fingers, because these are live servers.

You remove them from the world file, not the system. Then run emerge -cp
to seen what would be depcleaned. Nothing is uninstalled and nothing
stops working.

> > There was a script floating around that created a new world file that
> > contained all installed packages that were not a dependency of another
> > installed package. It's not a perfect fix, but pretty close.  
> 
> I gave a concrete example from one of our web servers where this would 
> remove something important.

How so? If anything that was not a dependency of something else was in
the world file, how could anything be removed?


-- 
Neil Bothwick

I'm not a complete idiot - several parts are missing.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Michael Mol]

On Mon, Jan 2, 2012 at 5:13 PM, Michael Orlitzky <michael@orlitzky.com> wrote:
> On 01/02/2012 04:58 PM, Michael Mol wrote:
>>
>>
>> Ah. I must have gotten confused at "So which ones can I remove?
>> Solutions involving time travel and/or losing customers will be
>> disqualified."
>>
>
> Sorry, this thread has gotten a little out of hand =)
>
> I think my point was: most solutions available to me now involve potential
> breakage. Others require me to be more careful 6 years ago. Neither of those
> is desirable.
>
> The current --update behavior makes this situation easy to get into. If
> there are no downsides to the old behavior (the point of this thread), then
> I think the old behavior is preferable.

I'd guess it's more architectural wrt the internals of portage. But
that's why I figure you'd have to ask the devs...

-- 
:wq

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

[Michael Orlitzky]

On 01/02/2012 05:41 PM, Neil Bothwick wrote:
> On Mon, 02 Jan 2012 16:33:04 -0500, Michael Orlitzky wrote:
>
>>> Yes they have. Remove anything in the least suspect and emerge -cp.
>>> Then emerge -n anything listed that you need.
>>
>> I don't know which ones I need, and I can't just remove them and cross
>> my fingers, because these are live servers.
>
> You remove them from the world file, not the system. Then run emerge -cp
> to seen what would be depcleaned. Nothing is uninstalled and nothing
> stops working.
>
>>> There was a script floating around that created a new world file that
>>> contained all installed packages that were not a dependency of another
>>> installed package. It's not a perfect fix, but pretty close.
>>
>> I gave a concrete example from one of our web servers where this would
>> remove something important.
>
> How so? If anything that was not a dependency of something else was in
> the world file, how could anything be removed?

I have both of these in world:

   dev-php/PEAR-Mail
   dev-php/PEAR-Mail_Mime

Let's say PEAR-Mail_Mime depends on PEAR-Mail -- it might, I haven't 
checked, it's just an example. And I remember installing PEAR-Mail_Mime: 
I needed it to receive binary attachments through a contact form on an 
internal site.

I suspect a customer had me install PEAR-Mail so that he could send some 
notifications via SMTP rather than sendmail(). Can I remove it from world?

At the moment, yes I can: PEAR-Mail_Mime depends on PEAR-Mail, so there 
will be no change in my --depclean output. But if I ever take down the 
internal site, and uninstall PEAR-Mail_Mime, depclean will want to 
remove PEAR-Mail, and break that guy's site. This is what that script 
would do.

If I know that I have been careful in the past, this is not a problem, 
since the contents of world will be accurate. However, I'm a little 
worried that I may have forgotten --oneshot and added PEAR-Mail by 
mistake on an upgrade. Now, I have to either risk breaking some 
customer's site, or leave PEAR-Mail in my world file forever.

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

[Alan McKinnon]

On Mon, 02 Jan 2012 16:18:23 -0500
Michael Orlitzky <michael@orlitzky.com> wrote:

> On 01/02/2012 04:11 PM, Alan McKinnon wrote:
> > cocktail
> > Neil's suggestion of sets sounds like what you want here.
> > Unfortunately it only works smoothly on first emerge (later on you
> > have to dig through dep graphs to find the full dep list):
> >
> > First run emerge -p to find all the packages that will be pulled in,
> > and add the whole lot to a set with a clear name that indicates it's
> > function. Then emerge that set. As you discover further deps you can
> > manually add them to the set
> >
> > It's quite a lot of extra work and you have to remember to do it,
> > but it has the benefit of being somewhat self-documenting, at least
> > in terms of having a record of what set pulled a package in
> > initially.
> >
> 
> Requires time travel, not a solution!


Eh? Did you read what I wrote?

You don't have to go back and figure it all out all over again, "emerge
-p <something>" tells you what needs to be emerged. Paste-edit that
into a set file and Bob's your Auntie.

What are you looking for here? Do you seek a magic way for portage to
know what you intended and why you did what you did when you did it?
Software can't do that.

-- 
Alan McKinnnon
alan.mckinnon@gmail.com

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

[Alan McKinnon]

On Mon, 02 Jan 2012 16:08:44 -0500
Michael Orlitzky <michael@orlitzky.com> wrote:


> Making your software punish its users isn't going to make them more 
> careful, it's going to make them stop using your software. If bash
> did an 'rm -rf /' when you mistyped a command[1], would you think,
> gee, I need to be more careful? Or would you think the guy who made
> it do that was an asshole?


That's an interesting question.

Moving slightly OT, I think most of the devs who worked on portage in
the past (starting with Daniel) have little clue about proper design
and just slapped stuff/features on with little thought. It might not
actually BE that way, but it sure LOOKS like it.

And now finally we have Zac, a brave man who has taken on the thankless
task of sorting the mess out. Most of his deep changes over the past
two years or so are to make things consistent within the overall grand
plan.

Stuff breaks badly when you do that. But it has to be done. Today it's
your turn to be on the sharp end. 


-- 
Alan McKinnnon
alan.mckinnon@gmail.com

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

[Alan McKinnon]

On Mon, 02 Jan 2012 18:11:15 -0500
Michael Orlitzky <michael@orlitzky.com> wrote:

> If I know that I have been careful in the past, this is not a
> problem, since the contents of world will be accurate. However, I'm a
> little worried that I may have forgotten --oneshot and added
> PEAR-Mail by mistake on an upgrade. Now, I have to either risk
> breaking some customer's site, or leave PEAR-Mail in my world file
> forever.

TwoIf I know that I have been careful in the past, this is not a
problem, since the contents of world will be accurate. However, I'm a
little worried that I may have forgotten --oneshot and added PEAR-Mail
by mistake on an upgrade. Now, I have to either risk breaking some 
customer's site, or leave PEAR-Mail in my world file forever. questions:

1. How do you propose any possible software could help with this?

2. Why do you care about those specific packages in world? Do they
cause a conflict or some other large problem? Personally I'd just leave
them in world


-- 
Alan McKinnnon
alan.mckinnon@gmail.com

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

[Alan McKinnon]

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

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

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

[Michael Orlitzky]

On 01/02/2012 06:29 PM, Alan McKinnon wrote:
> On Mon, 02 Jan 2012 18:11:15 -0500
> Michael Orlitzky<michael@orlitzky.com>  wrote:
>
>> If I know that I have been careful in the past, this is not a
>> problem, since the contents of world will be accurate. However, I'm a
>> little worried that I may have forgotten --oneshot and added
>> PEAR-Mail by mistake on an upgrade. Now, I have to either risk
>> breaking some customer's site, or leave PEAR-Mail in my world file
>> forever.
>
> TwoIf I know that I have been careful in the past, this is not a
> problem, since the contents of world will be accurate. However, I'm a
> little worried that I may have forgotten --oneshot and added PEAR-Mail
> by mistake on an upgrade. Now, I have to either risk breaking some
> customer's site, or leave PEAR-Mail in my world file forever. questions:
>
> 1. How do you propose any possible software could help with this?

Well, before the change to --update, I kept all of my world files clean 
for years. The problem still would have existed if I had screwed up, but 
it was much harder to screw up.

Software can't help at this point. That is, ultimately, my reason for 
preferring the old behavior. Just the knowledge that it is easy to 
accidentally add a package to world makes it dangerous to clean up 
manually. I think, "Maybe I added this accidentally, since it's so easy 
to forget --oneshot. Better leave it alone."


> 2. Why do you care about those specific packages in world? Do they
> cause a conflict or some other large problem? Personally I'd just leave
> them in world

That's the plan.

Most of these servers have been running forever. I've never reformatted 
a gentoo box. If every once in a while a package gets added to world, 
it's not a problem today or tomorrow, but it might be in ten years if 
these boxes are still up -- and I expect some of them to be.

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

[Michael Orlitzky]

On 01/02/2012 06:25 PM, Alan McKinnon wrote:
> On Mon, 02 Jan 2012 16:08:44 -0500
> Michael Orlitzky<michael@orlitzky.com>  wrote:
>
>
>> Making your software punish its users isn't going to make them more
>> careful, it's going to make them stop using your software. If bash
>> did an 'rm -rf /' when you mistyped a command[1], would you think,
>> gee, I need to be more careful? Or would you think the guy who made
>> it do that was an asshole?
>
>
> That's an interesting question.
>
> Moving slightly OT, I think most of the devs who worked on portage in
> the past (starting with Daniel) have little clue about proper design
> and just slapped stuff/features on with little thought. It might not
> actually BE that way, but it sure LOOKS like it.
>
> And now finally we have Zac, a brave man who has taken on the thankless
> task of sorting the mess out. Most of his deep changes over the past
> two years or so are to make things consistent within the overall grand
> plan.
>
> Stuff breaks badly when you do that. But it has to be done. Today it's
> your turn to be on the sharp end.

I'm fine with suffering a little for the greater good, but is the new 
behavior better in any tangible way?

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

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 2439 bytes --]

On Mon, 02 Jan 2012 18:11:15 -0500, Michael Orlitzky wrote:

> > How so? If anything that was not a dependency of something else was in
> > the world file, how could anything be removed?  
> 
> I have both of these in world:
> 
>    dev-php/PEAR-Mail
>    dev-php/PEAR-Mail_Mime
> 
> Let's say PEAR-Mail_Mime depends on PEAR-Mail -- it might, I haven't 
> checked, it's just an example. And I remember installing
> PEAR-Mail_Mime: I needed it to receive binary attachments through a
> contact form on an internal site.
> 
> I suspect a customer had me install PEAR-Mail so that he could send
> some notifications via SMTP rather than sendmail(). Can I remove it
> from world?
> 
> At the moment, yes I can: PEAR-Mail_Mime depends on PEAR-Mail, so there 
> will be no change in my --depclean output. But if I ever take down the 
> internal site, and uninstall PEAR-Mail_Mime, depclean will want to 
> remove PEAR-Mail, and break that guy's site. This is what that script 
> would do.
> 
> If I know that I have been careful in the past, this is not a problem, 
> since the contents of world will be accurate. However, I'm a little 
> worried that I may have forgotten --oneshot and added PEAR-Mail by 
> mistake on an upgrade. Now, I have to either risk breaking some 
> customer's site, or leave PEAR-Mail in my world file forever.

nothing can protect you from something going wrong with this. What if you
had installed dev-php/PEAR-Mail_Mime first? It would have pulled in
dev-php/PEAR-Mail and you would not have had to install that for the
other customer and it would not be in world. If the first customer no
longer needs his packages, dev-php/PEAR-Mail would still be subject to
depcleaning, no matter how emerge -u behaved.

Where you have a situation where packages are dependencies of factors
outside of portage, you have to take your own steps to manage this. The
only software that can completely help you with that is already installed
between your ears. As stated previously, I would use sets as a
self-documenting method of doing this, but anything involving adequate
record keeping should do.

As Alan indicated, there is no real harm in having the odd spurious
package in world aside from a tendency to bloat.


-- 
Neil Bothwick

What do you get if you cross an agnostic, an insomniac and adyslexic?
Someone who lies awake at night wondering if there really is a dog.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Michael Mol]

On Mon, Jan 2, 2012 at 6:33 PM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> On Mon, 2 Jan 2012 11:20:19 -0500
> Michael Mol <mikemol@gmail.com> wrote:
>
>> On Mon, Jan 2, 2012 at 11:16 AM, Michael Mol <mikemol@gmail.com>
>> wrote:
>> > On Mon, Jan 2, 2012 at 11:09 AM, Michael Orlitzky
>> > <michael@orlitzky.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

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

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 804 bytes --]

On Mon, 02 Jan 2012 18:49:50 -0500, Michael Orlitzky wrote:

> > And now finally we have Zac, a brave man who has taken on the
> > thankless task of sorting the mess out. Most of his deep changes over
> > the past two years or so are to make things consistent within the
> > overall grand plan.
> >
> > Stuff breaks badly when you do that. But it has to be done. Today it's
> > your turn to be on the sharp end.  
> 
> I'm fine with suffering a little for the greater good, but is the new 
> behavior better in any tangible way?

It is reasonable to assume that the answer to that question is "yes". Any
other answer raises the question "why did Zac spend so much effort
recoding portage just to piss off the odd user?".


-- 
Neil Bothwick

Linux users do it without paying a Bill

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Dale]

Neil Bothwick wrote:
> On Mon, 02 Jan 2012 18:49:50 -0500, Michael Orlitzky wrote:
>
>>> And now finally we have Zac, a brave man who has taken on the
>>> thankless task of sorting the mess out. Most of his deep changes over
>>> the past two years or so are to make things consistent within the
>>> overall grand plan.
>>>
>>> Stuff breaks badly when you do that. But it has to be done. Today it's
>>> your turn to be on the sharp end.
>> I'm fine with suffering a little for the greater good, but is the new
>> behavior better in any tangible way?
> It is reasonable to assume that the answer to that question is "yes". Any
> other answer raises the question "why did Zac spend so much effort
> recoding portage just to piss off the odd user?".
>
>


I always knew I was "odd".  Looks like I have some company tho.  Welcome 
to the "odd user" group Michael.

Dale

:-)  :-)

-- 
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!

Miss the compile output?  Hint:
EMERGE_DEFAULT_OPTS="--quiet-build=n"

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

[Michael Orlitzky]

On 01/02/2012 07:04 PM, Neil Bothwick wrote:
> On Mon, 02 Jan 2012 18:49:50 -0500, Michael Orlitzky wrote:
>
>>> And now finally we have Zac, a brave man who has taken on the
>>> thankless task of sorting the mess out. Most of his deep changes over
>>> the past two years or so are to make things consistent within the
>>> overall grand plan.
>>>
>>> Stuff breaks badly when you do that. But it has to be done. Today it's
>>> your turn to be on the sharp end.
>>
>> I'm fine with suffering a little for the greater good, but is the new
>> behavior better in any tangible way?
>
> It is reasonable to assume that the answer to that question is "yes". Any
> other answer raises the question "why did Zac spend so much effort
> recoding portage just to piss off the odd user?".

Hah! Many people here are probably employed in IT, software development, 
or system administration where the job description can be summed up as 
"unfixing things that weren't broken."

We all implicitly trust the devs with our systems, of course, but maybe 
it was announced to little protest and that was reason enough?

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

[Michael Orlitzky]

On 01/02/2012 07:22 PM, Dale wrote:
>
>
> I always knew I was "odd".  Looks like I have some company tho.  Welcome
> to the "odd user" group Michael.

It ain't us =)

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

[Alan McKinnon]

On Mon, 02 Jan 2012 18:48:48 -0500
Michael Orlitzky <michael@orlitzky.com> wrote:

> > 2. Why do you care about those specific packages in world? Do they
> > cause a conflict or some other large problem? Personally I'd just
> > leave them in world  
> 
> That's the plan.
> 
> Most of these servers have been running forever. I've never
> reformatted a gentoo box. If every once in a while a package gets
> added to world, it's not a problem today or tomorrow, but it might be
> in ten years if these boxes are still up -- and I expect some of them
> to be.

The way I see it there are actually two issues here, and the thread is
conflating them. 

One is maintaining what is in world, dealing with bloat if it
happens, and depcleaning stuffs. All this is the province of portage.

The other is *why* you put that package there in the first place
because now you must maintain it. You chose to install a lowish level
lib for reasons of your own and forgot to document it and portage
cannot help you.

So your actual problem is that you relied on an arbitrary behaviour of
portage from the days when the standard was "whatever portage does
today" and you are unhappy because for you that is now broken.

But no-one ever promised you that behaviour in a stable API.

-- 
Alan McKinnnon
alan.mckinnon@gmail.com

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

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 675 bytes --]

On Mon, 02 Jan 2012 21:00:12 -0500, Michael Orlitzky wrote:

> > It is reasonable to assume that the answer to that question is "yes".
> > Any other answer raises the question "why did Zac spend so much effort
> > recoding portage just to piss off the odd user?".  
> 
> Hah! Many people here are probably employed in IT, software
> development, or system administration where the job description can be
> summed up as "unfixing things that weren't broken."

AFAIK, Zac is not being paid for developing portage, so making changes
to justify his employment are not necessary.


-- 
Neil Bothwick

She's always late. Her ancestors arrived on the June flower.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Tanstaafl]

On 2012-01-02 3:48 PM, Neil Bothwick <neil@digimed.co.uk> wrote:
> On Mon, 2 Jan 2012 09:29:57 -0800, Mark Knecht wrote:
>
>> That works for the case where the software is managed by portage,
>> which is likely 99.9999% of what's on Gentoo systems worldwide. It
>> doesn't work however for the odd case where I write some little
>> program which requires a library (ta-lib in my portage file) and I
>> don't write an ebuild to build it. I've never bothered to learn to do
>> my own ebuilds but at some level it would be a good idea, and I think
>> it would address Mr. Orlitsky's issue about what his users need and
>> why.
>
> That's more easily handled with sets. No ebuild writing skills are needed
> and there's no danger of atoms being accidentally added to the set.

This sounds very interesting...

Neil, is the use of sets fully documented somewhere? I don't recall 
reading about them in the Handbook, but its been a while since I read it 
(and don't remember if I ever did cover to cover)...

Thanks!

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

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 850 bytes --]

On Tue, 03 Jan 2012 06:49:45 -0500, Tanstaafl wrote:

> Neil, is the use of sets fully documented somewhere? I don't recall 
> reading about them in the Handbook, but its been a while since I read
> it (and don't remember if I ever did cover to cover)...

I can't recall where I found the documentation, but you can create a set
in /etc/portage/sets/ with one atom per line. Then emerge @setname to
install the packages.

I find them really useful. For example I have a @base set listing all the
packages I want on a new install (tmux, gentoolkit, portage-utils etc) so
I can copy it to a new install and emerge @base to make sure I have all
the tools I normally use.


-- 
Neil Bothwick

The word 'Windows' is a word out of an old dialect of the Apaches.
It means: 'White man staring through glass-screen onto an hourglass...')

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 1730 bytes --]

On Tuesday 03 Jan 2012 02:00:48 Michael Orlitzky wrote:
> On 01/02/2012 07:22 PM, Dale wrote:
> > I always knew I was "odd".  Looks like I have some company tho.  Welcome
> > to the "odd user" group Michael.
> 
> It ain't us =)

Nope.  It ain't just you.  It's me too.  ;-)

I'd rather the old default behaviour was retained/returned to.  I have to 
admit even after all this time I will occasionally forget and run emerge -u 
some_package, only to notice that it was added into world at the end of the 
emerge.  Even worse, it wasn't updated (because no update was available) but 
was just added in world all the same.

Of course when I notice this I go and remove it from world manually and make a 
mental note not to do this again.  When I miss it, the package ends up in 
world.  :-(

However, I do wonder how confused could a new user end up being with this 
(superficially) inconsistent behaviour.  The -u option works fine on world (it 
just updates packages already in world, but not on individual packages (it 
updates *and* adds said packages in world).

I understand the logic, but for the reasons explained by Michael and Dale I 
also prefer the old behaviour to be the default:  nothing gets added in world 
as a result of updating alone.  An enotice message that informs the user that 
just updating the particular package(s) does not mean they are added to the 
world file and won't be automatically updated when running 'emerge -u world' in 
the future, would educate users, along with options for adding the said 
packages in world.

Of course, the opposite will work too;  flashing a fat enotice to educate us 
old dogs to remember to run -1 instead of -u.
-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Hinnerk van Bruinehsen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02.01.2012 18:58, Michael Orlitzky wrote:
> On 01/02/12 12:47, Mark Knecht wrote:
>> 
>> Again, 'equery depends' will tell you if any package locatable
>> through the @world hierarchy needs the package. No need to
>> uninstall anything to do that level of investigation.
>> revdep-rebuild -I is also useful, although more historically than
>> now.
>> 
> 
> This was essentially Michal Mol's suggestion, and I gave an
> example where it would remove something important.
> 
> 
>> Really, the proposal to 'fix --update' doesn't address really
>> knowing what your system is running and why. Get to the root of
>> that and the --update thing becomes the non-issue that many of us
>> think it is.
>> 
> 
> This would be a suggestion to travel back in time and document
> something that I have no way of knowing now.
> 
You could create your own overlay with "meta"-ebuilds, e. g.
system-maintenance, customer1, customer2.
Inside the ebuilds you define depends on the packages the customer wants.
Doing so you could wipe everything except the "meta"-ebuilds from world.
When a customer quits you can unmerge his or her "meta"-ebuild and
depclean.
If you add everything needed to the respective "meta"-ebuild, you'll
always be on the safe side.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPAwtEAAoJEJwwOFaNFkYcCIAIAMjC7zIVaGq0ilbfhvWW2lHh
X1rsaLGcXIJDEAi6kP69aDyzqP3QSmZFXRid8B2eMLJ+1ZZI/c+VqBLgE8zDU3ai
TbamRYeb/kdD2CplanLhDDkQ04DVYhYZXWBJkC7e3IL4assF+2wjiwOsG8Dh0HMh
oZ3bbkaR51F5kSSl3xVcWh63B+aU7Zqc3erAjL36mBkoaTOYIYjm7f2uo9vxR2Gv
91d4l5sfrOw7JTtSDMv++6gdrnS8Imh4RrTH3Kd+rUsM2VzzCnnCrWtqTYOhP3JH
LFFN55McpjLwHwc0AumG0eQZY+vk7xdS1Ev9bSCd35LwrogluPj5QVhUSwbS//8=
=cJtw
-----END PGP SIGNATURE-----

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

[Alan McKinnon]

On Tue, 03 Jan 2012 15:05:56 +0100
Hinnerk van Bruinehsen <h.v.bruinehsen@fu-berlin.de> wrote:

> >> Really, the proposal to 'fix --update' doesn't address really
> >> knowing what your system is running and why. Get to the root of
> >> that and the --update thing becomes the non-issue that many of us
> >> think it is.
> >>   
> > 
> > This would be a suggestion to travel back in time and document
> > something that I have no way of knowing now.
> >   
> You could create your own overlay with "meta"-ebuilds, e. g.
> system-maintenance, customer1, customer2.
> Inside the ebuilds you define depends on the packages the customer
> wants. Doing so you could wipe everything except the "meta"-ebuilds
> from world. When a customer quits you can unmerge his or her
> "meta"-ebuild and depclean.
> If you add everything needed to the respective "meta"-ebuild, you'll
> always be on the safe side.


Sets do exactly the same thing simply without all the added verbiage of
an ebuild.

The *only* thing required to bring about the solution you describe is
the information in the *DEPEND of the meta-ebuild, and that is all that
is in a set.



-- 
Alan McKinnnon
alan.mckinnon@gmail.com

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

[Hinnerk van Bruinehsen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03.01.2012 15:47, Alan McKinnon wrote:
> On Tue, 03 Jan 2012 15:05:56 +0100 Hinnerk van Bruinehsen
> <h.v.bruinehsen@fu-berlin.de> wrote:
> 
>>>> Really, the proposal to 'fix --update' doesn't address
>>>> really knowing what your system is running and why. Get to
>>>> the root of that and the --update thing becomes the non-issue
>>>> that many of us think it is.
>>>> 
>>> 
>>> This would be a suggestion to travel back in time and document 
>>> something that I have no way of knowing now.
>>> 
>> You could create your own overlay with "meta"-ebuilds, e. g. 
>> system-maintenance, customer1, customer2. Inside the ebuilds you
>> define depends on the packages the customer wants. Doing so you
>> could wipe everything except the "meta"-ebuilds from world. When
>> a customer quits you can unmerge his or her "meta"-ebuild and
>> depclean. If you add everything needed to the respective
>> "meta"-ebuild, you'll always be on the safe side.
> 
> 
> Sets do exactly the same thing simply without all the added
> verbiage of an ebuild.
> 
> The *only* thing required to bring about the solution you describe
> is the information in the *DEPEND of the meta-ebuild, and that is
> all that is in a set.
> 

Then I should try to find some information on sets (custom defined
ones). Thank you for the hint!

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPAxXjAAoJEJwwOFaNFkYcP64H/0sl77a1uFXW5hL0hM1A5fSN
PzKAErLc6inDRzzs0KnsDrFgkDhmPdebga2JG99IGzk+fpS77Cdu6SQUrOvkRwlF
7uzRXXCSCPxOnaHcP6ONVekeOr2HObgc6xPg1fZ8/AK2sbBozjX3N+HTgE0Wl8fW
CReSK9kLmseN0YZULD0FvpuvHHs5Rda0VnFl1huY8JJWzUUOxkEkkOcrVCKjLC0I
SDO4i5UCtG/pKCUby1/r1m06tR5WuiDm/hQ8/wEMB4C7/a4tZIJ0HcJjtAMYZOvH
GIEP2uUIPbhC/rWwnTeM12e0ukWkNVwEnu/dyIhVhV8JOaEJi6ADgKRgimvWJo8=
=d+9f
-----END PGP SIGNATURE-----

(Was) Re: [gentoo-user] emerge --update behavior

[Michael Mol]

Hinnerk van Bruinehsen wrote:
> On 02.01.2012 18:58, Michael Orlitzky wrote:
>> On 01/02/12 12:47, Mark Knecht wrote:
>>>
>>> Again, 'equery depends' will tell you if any package locatable
>>> through the @world hierarchy needs the package. No need to
>>> uninstall anything to do that level of investigation.
>>> revdep-rebuild -I is also useful, although more historically than
>>> now.
>>>
> 
>> This was essentially Michal Mol's suggestion, and I gave an
>> example where it would remove something important.
> 
> 
>>> Really, the proposal to 'fix --update' doesn't address really
>>> knowing what your system is running and why. Get to the root of
>>> that and the --update thing becomes the non-issue that many of us
>>> think it is.
>>>
> 
>> This would be a suggestion to travel back in time and document
>> something that I have no way of knowing now.
> 
> You could create your own overlay with "meta"-ebuilds, e. g.
> system-maintenance, customer1, customer2.
> Inside the ebuilds you define depends on the packages the customer wants.
> Doing so you could wipe everything except the "meta"-ebuilds from world.
> When a customer quits you can unmerge his or her "meta"-ebuild and
> depclean.
> If you add everything needed to the respective "meta"-ebuild, you'll
> always be on the safe side.
> 
> 

Getting EnigMail set up on a Seamonkey/Win7 box, and Enigmail is
complaining that your signature is unverified. I don't know/understand
PGP/GPG all that well, but I think this is something you're supposed to
be able to fix on your end. If that's not the case, let me know, and
I'll get it fixed on my end. :)

gpg command line and output:
C:\Program Files (x86)\GNU\GnuPG\gpg.exe
gpg: Signature made 01/03/12 09:05:56 using RSA key ID 8D16461C
gpg: Can't check signature: public key not found

Re: (Was) Re: [gentoo-user] emerge --update behavior

[Michael Mol]

Michael Mol wrote:
> Hinnerk van Bruinehsen wrote:
>> On 02.01.2012 18:58, Michael Orlitzky wrote:
>>> On 01/02/12 12:47, Mark Knecht wrote:
>>>>
>>>> Again, 'equery depends' will tell you if any package locatable
>>>> through the @world hierarchy needs the package. No need to
>>>> uninstall anything to do that level of investigation.
>>>> revdep-rebuild -I is also useful, although more historically than
>>>> now.
>>>>
>>
>>> This was essentially Michal Mol's suggestion, and I gave an
>>> example where it would remove something important.
>>
>>
>>>> Really, the proposal to 'fix --update' doesn't address really
>>>> knowing what your system is running and why. Get to the root of
>>>> that and the --update thing becomes the non-issue that many of us
>>>> think it is.
>>>>
>>
>>> This would be a suggestion to travel back in time and document
>>> something that I have no way of knowing now.
>>
>> You could create your own overlay with "meta"-ebuilds, e. g.
>> system-maintenance, customer1, customer2.
>> Inside the ebuilds you define depends on the packages the customer wants.
>> Doing so you could wipe everything except the "meta"-ebuilds from world.
>> When a customer quits you can unmerge his or her "meta"-ebuild and
>> depclean.
>> If you add everything needed to the respective "meta"-ebuild, you'll
>> always be on the safe side.
>>
>>
> 
> Getting EnigMail set up on a Seamonkey/Win7 box, and Enigmail is
> complaining that your signature is unverified. I don't know/understand
> PGP/GPG all that well, but I think this is something you're supposed to
> be able to fix on your end. If that's not the case, let me know, and
> I'll get it fixed on my end. :)
> 
> gpg command line and output:
> C:\Program Files (x86)\GNU\GnuPG\gpg.exe
> gpg: Signature made 01/03/12 09:05:56 using RSA key ID 8D16461C
> gpg: Can't check signature: public key not found

Doh...that was supposed to go directly to Hinnerk. "Reply to sender
only" my hind leg...

Re: (Was) Re: [gentoo-user] emerge --update behavior

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 2373 bytes --]

On Tuesday 03 Jan 2012 14:55:38 Michael Mol wrote:
> Michael Mol wrote:
> > Hinnerk van Bruinehsen wrote:
> >> On 02.01.2012 18:58, Michael Orlitzky wrote:
> >>> On 01/02/12 12:47, Mark Knecht wrote:
> >>>> Again, 'equery depends' will tell you if any package locatable
> >>>> through the @world hierarchy needs the package. No need to
> >>>> uninstall anything to do that level of investigation.
> >>>> revdep-rebuild -I is also useful, although more historically than
> >>>> now.
> >>> 
> >>> This was essentially Michal Mol's suggestion, and I gave an
> >>> example where it would remove something important.
> >>> 
> >>>> Really, the proposal to 'fix --update' doesn't address really
> >>>> knowing what your system is running and why. Get to the root of
> >>>> that and the --update thing becomes the non-issue that many of us
> >>>> think it is.
> >>> 
> >>> This would be a suggestion to travel back in time and document
> >>> something that I have no way of knowing now.
> >> 
> >> You could create your own overlay with "meta"-ebuilds, e. g.
> >> system-maintenance, customer1, customer2.
> >> Inside the ebuilds you define depends on the packages the customer
> >> wants. Doing so you could wipe everything except the "meta"-ebuilds
> >> from world. When a customer quits you can unmerge his or her
> >> "meta"-ebuild and depclean.
> >> If you add everything needed to the respective "meta"-ebuild, you'll
> >> always be on the safe side.
> > 
> > Getting EnigMail set up on a Seamonkey/Win7 box, and Enigmail is
> > complaining that your signature is unverified. I don't know/understand
> > PGP/GPG all that well, but I think this is something you're supposed to
> > be able to fix on your end. If that's not the case, let me know, and
> > I'll get it fixed on my end. :)
> > 
> > gpg command line and output:
> > C:\Program Files (x86)\GNU\GnuPG\gpg.exe
> > gpg: Signature made 01/03/12 09:05:56 using RSA key ID 8D16461C
> > gpg: Can't check signature: public key not found
> 
> Doh...that was supposed to go directly to Hinnerk. "Reply to sender
> only" my hind leg...

Looks like a recently created gpg key.  Assuming the owner has uploaded it to 
a public key server, it seems likely that it has not propagated across the 
public servers yet and your enigmail plugin alerts you about it.
-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: (Was) Re: [gentoo-user] emerge --update behavior

[Michael Mol]

Mick wrote:
> On Tuesday 03 Jan 2012 14:55:38 Michael Mol wrote:
>> Michael Mol wrote:
>>> Hinnerk van Bruinehsen wrote:
>>>> On 02.01.2012 18:58, Michael Orlitzky wrote:
>>>>> On 01/02/12 12:47, Mark Knecht wrote:
>>>>>> Again, 'equery depends' will tell you if any package locatable
>>>>>> through the @world hierarchy needs the package. No need to
>>>>>> uninstall anything to do that level of investigation.
>>>>>> revdep-rebuild -I is also useful, although more historically than
>>>>>> now.
>>>>>
>>>>> This was essentially Michal Mol's suggestion, and I gave an
>>>>> example where it would remove something important.
>>>>>
>>>>>> Really, the proposal to 'fix --update' doesn't address really
>>>>>> knowing what your system is running and why. Get to the root of
>>>>>> that and the --update thing becomes the non-issue that many of us
>>>>>> think it is.
>>>>>
>>>>> This would be a suggestion to travel back in time and document
>>>>> something that I have no way of knowing now.
>>>>
>>>> You could create your own overlay with "meta"-ebuilds, e. g.
>>>> system-maintenance, customer1, customer2.
>>>> Inside the ebuilds you define depends on the packages the customer
>>>> wants. Doing so you could wipe everything except the "meta"-ebuilds
>>>> from world. When a customer quits you can unmerge his or her
>>>> "meta"-ebuild and depclean.
>>>> If you add everything needed to the respective "meta"-ebuild, you'll
>>>> always be on the safe side.
>>>
>>> Getting EnigMail set up on a Seamonkey/Win7 box, and Enigmail is
>>> complaining that your signature is unverified. I don't know/understand
>>> PGP/GPG all that well, but I think this is something you're supposed to
>>> be able to fix on your end. If that's not the case, let me know, and
>>> I'll get it fixed on my end. :)
>>>
>>> gpg command line and output:
>>> C:\Program Files (x86)\GNU\GnuPG\gpg.exe
>>> gpg: Signature made 01/03/12 09:05:56 using RSA key ID 8D16461C
>>> gpg: Can't check signature: public key not found
>>
>> Doh...that was supposed to go directly to Hinnerk. "Reply to sender
>> only" my hind leg...
> 
> Looks like a recently created gpg key.  Assuming the owner has uploaded it to 
> a public key server, it seems likely that it has not propagated across the 
> public servers yet and your enigmail plugin alerts you about it.

Mick, yours gives me the same error:

gpg command line and output:
C:\Program Files (x86)\GNU\GnuPG\gpg.exe
gpg: Signature made 01/03/12 11:01:03 using DSA key ID 792968B6
gpg: Can't check signature: public key not found

Though trying querying for 8D16461C or 792968B6 at
pool.sks-keyservers.net or subkeys.pgp.net gives me "no key found" errors.

Re: (Was) Re: [gentoo-user] emerge --update behavior

[Michael Mol]

Mick wrote:
> On Tuesday 03 Jan 2012 14:55:38 Michael Mol wrote:
>> Michael Mol wrote:
>>> Hinnerk van Bruinehsen wrote:
>>>> On 02.01.2012 18:58, Michael Orlitzky wrote:
>>>>> On 01/02/12 12:47, Mark Knecht wrote:
>>>>>> Again, 'equery depends' will tell you if any package locatable
>>>>>> through the @world hierarchy needs the package. No need to
>>>>>> uninstall anything to do that level of investigation.
>>>>>> revdep-rebuild -I is also useful, although more historically than
>>>>>> now.
>>>>>
>>>>> This was essentially Michal Mol's suggestion, and I gave an
>>>>> example where it would remove something important.
>>>>>
>>>>>> Really, the proposal to 'fix --update' doesn't address really
>>>>>> knowing what your system is running and why. Get to the root of
>>>>>> that and the --update thing becomes the non-issue that many of us
>>>>>> think it is.
>>>>>
>>>>> This would be a suggestion to travel back in time and document
>>>>> something that I have no way of knowing now.
>>>>
>>>> You could create your own overlay with "meta"-ebuilds, e. g.
>>>> system-maintenance, customer1, customer2.
>>>> Inside the ebuilds you define depends on the packages the customer
>>>> wants. Doing so you could wipe everything except the "meta"-ebuilds
>>>> from world. When a customer quits you can unmerge his or her
>>>> "meta"-ebuild and depclean.
>>>> If you add everything needed to the respective "meta"-ebuild, you'll
>>>> always be on the safe side.
>>>
>>> Getting EnigMail set up on a Seamonkey/Win7 box, and Enigmail is
>>> complaining that your signature is unverified. I don't know/understand
>>> PGP/GPG all that well, but I think this is something you're supposed to
>>> be able to fix on your end. If that's not the case, let me know, and
>>> I'll get it fixed on my end. :)
>>>
>>> gpg command line and output:
>>> C:\Program Files (x86)\GNU\GnuPG\gpg.exe
>>> gpg: Signature made 01/03/12 09:05:56 using RSA key ID 8D16461C
>>> gpg: Can't check signature: public key not found
>>
>> Doh...that was supposed to go directly to Hinnerk. "Reply to sender
>> only" my hind leg...
> 
> Looks like a recently created gpg key.  Assuming the owner has uploaded it to 
> a public key server, it seems likely that it has not propagated across the 
> public servers yet and your enigmail plugin alerts you about it.

Found most of the problem; Enigmail defaulted to an empty "automatically
download keys for signature vereification from the following keyserver"
field. Fixed that, and things started working a little better. (Herr Van
Bruinehsen's key doesn't seem to have propagated, yes, but now yours
works fine. :) )

Re: (Was) Re: [gentoo-user] emerge --update behavior

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 1414 bytes --]

On Tuesday 03 Jan 2012 16:18:20 Michael Mol wrote:

> Mick, yours gives me the same error:
> 
> gpg command line and output:
> C:\Program Files (x86)\GNU\GnuPG\gpg.exe
> gpg: Signature made 01/03/12 11:01:03 using DSA key ID 792968B6
> gpg: Can't check signature: public key not found
> 
> Though trying querying for 8D16461C or 792968B6 at
> pool.sks-keyservers.net or subkeys.pgp.net gives me "no key found" errors.

Ahh ... that's probably different then, because my public key has been knocking 
around for a while.

$ /usr/bin/gpg2 --keyserver hkp://keys.gnupg.net --search-keys 
"michaelkintzios@gmail.com"
gpg: enabled debug flags: memstat
gpg: searching for "michaelkintzios@gmail.com" from hkp server keys.gnupg.net
(1)	Michael Kintzios (Mick) <michaelkintzios@gmail.com>
	  1024 bit DSA key 792968B6, created: 2009-04-25
... [snip]


While Hinnerk's key is not found:


$ /usr/bin/gpg2 --keyserver hkp://keys.gnupg.net --search-keys 
"h.v.bruinehsen@fu-berlin.de"
gpg: enabled debug flags: memstat
gpg: searching for "h.v.bruinehsen@fu-berlin.de" from hkp server 
keys.gnupg.net
gpg: key "h.v.bruinehsen@fu-berlin.de" not found on keyserver


Have you specified a keyserver to be used as a default in your setup?  I use 
hkp://keys.gnupg.net which operates a round robin function on each connection 
so as to not over-burden individual servers.
-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: (Was) Re: [gentoo-user] emerge --update behavior

[Michael Mol]

Mick wrote:
> On Tuesday 03 Jan 2012 16:18:20 Michael Mol wrote:
> 
>> Mick, yours gives me the same error:
>>
>> gpg command line and output:
>> C:\Program Files (x86)\GNU\GnuPG\gpg.exe
>> gpg: Signature made 01/03/12 11:01:03 using DSA key ID 792968B6
>> gpg: Can't check signature: public key not found
>>
>> Though trying querying for 8D16461C or 792968B6 at
>> pool.sks-keyservers.net or subkeys.pgp.net gives me "no key found" errors.
> 
> Ahh ... that's probably different then, because my public key has been knocking 
> around for a while.
> 
> $ /usr/bin/gpg2 --keyserver hkp://keys.gnupg.net --search-keys 
> "michaelkintzios@gmail.com"
> gpg: enabled debug flags: memstat
> gpg: searching for "michaelkintzios@gmail.com" from hkp server keys.gnupg.net
> (1)	Michael Kintzios (Mick) <michaelkintzios@gmail.com>
> 	  1024 bit DSA key 792968B6, created: 2009-04-25
> ... [snip]
> 
> 
> While Hinnerk's key is not found:
> 
> 
> $ /usr/bin/gpg2 --keyserver hkp://keys.gnupg.net --search-keys 
> "h.v.bruinehsen@fu-berlin.de"
> gpg: enabled debug flags: memstat
> gpg: searching for "h.v.bruinehsen@fu-berlin.de" from hkp server 
> keys.gnupg.net
> gpg: key "h.v.bruinehsen@fu-berlin.de" not found on keyserver
> 
> 
> Have you specified a keyserver to be used as a default in your setup?  I use 
> hkp://keys.gnupg.net which operates a round robin function on each connection 
> so as to not over-burden individual servers.

As noted, got it working. Using pool.sks-keyservers.net. Thanks. :)

Re: (Was) Re: [gentoo-user] emerge --update behavior

[Hinnerk van Bruinehsen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03.01.2012 18:39, Mick wrote:
> On Tuesday 03 Jan 2012 16:18:20 Michael Mol wrote:
> 
>> Mick, yours gives me the same error:
>> 
>> gpg command line and output: C:\Program Files
>> (x86)\GNU\GnuPG\gpg.exe gpg: Signature made 01/03/12 11:01:03
>> using DSA key ID 792968B6 gpg: Can't check signature: public key
>> not found
>> 
>> Though trying querying for 8D16461C or 792968B6 at 
>> pool.sks-keyservers.net or subkeys.pgp.net gives me "no key
>> found" errors.
> 
> Ahh ... that's probably different then, because my public key has
> been knocking around for a while.
> 
> $ /usr/bin/gpg2 --keyserver hkp://keys.gnupg.net --search-keys 
> "michaelkintzios@gmail.com" gpg: enabled debug flags: memstat gpg:
> searching for "michaelkintzios@gmail.com" from hkp server
> keys.gnupg.net (1)	Michael Kintzios (Mick)
> <michaelkintzios@gmail.com> 1024 bit DSA key 792968B6, created:
> 2009-04-25 ... [snip]
> 
> 
> While Hinnerk's key is not found:
> 
> 
> $ /usr/bin/gpg2 --keyserver hkp://keys.gnupg.net --search-keys 
> "h.v.bruinehsen@fu-berlin.de" gpg: enabled debug flags: memstat 
> gpg: searching for "h.v.bruinehsen@fu-berlin.de" from hkp server 
> keys.gnupg.net gpg: key "h.v.bruinehsen@fu-berlin.de" not found on
> keyserver
> 
> 
> Have you specified a keyserver to be used as a default in your
> setup?  I use hkp://keys.gnupg.net which operates a round robin
> function on each connection so as to not over-burden individual
> servers.

It seems like the 'Upload key' function of my enigmail doesn't work. I
uploaded the key manually and now I can find it.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPA0BTAAoJEJwwOFaNFkYcTkwH/1aClDV0qLS3zWF2qs9BjVXn
SZGaYsWv1aM1zranLjS4s2st6bACuKct3twN1B2s/h3m6kRxjGaXVzowvHqsv/yu
Py/5HBvBV5X45kflyLG/cJA+Ti9uMMdH5D3J7sm6nRr2mFW1+jbulBJZ2W9W1HMg
w2QbMYsDwTkw8xLwlk0/2j3x6rKVwD9oLkYhQEuif51aj1OoWuu8pyCyp0WFUkzl
cLizruB/a1UfAU9H+Hv1sdBshY3uJ7dORvzdvfKautsW/WEXjHwqLHvcyOIQ2blN
AMwiUj1VMm4jlP1BUzU3OBt6YQDO/LXMppRTv70eibMMScVgmFUUjGC3X5m4H1Y=
=c4Iq
-----END PGP SIGNATURE-----

Re: (Was) Re: [gentoo-user] emerge --update behavior

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 2213 bytes --]

On Tuesday 03 Jan 2012 17:52:19 Hinnerk van Bruinehsen wrote:
> On 03.01.2012 18:39, Mick wrote:
> > On Tuesday 03 Jan 2012 16:18:20 Michael Mol wrote:
> >> Mick, yours gives me the same error:
> >> 
> >> gpg command line and output: C:\Program Files
> >> (x86)\GNU\GnuPG\gpg.exe gpg: Signature made 01/03/12 11:01:03
> >> using DSA key ID 792968B6 gpg: Can't check signature: public key
> >> not found
> >> 
> >> Though trying querying for 8D16461C or 792968B6 at
> >> pool.sks-keyservers.net or subkeys.pgp.net gives me "no key
> >> found" errors.
> > 
> > Ahh ... that's probably different then, because my public key has
> > been knocking around for a while.
> > 
> > $ /usr/bin/gpg2 --keyserver hkp://keys.gnupg.net --search-keys
> > "michaelkintzios@gmail.com" gpg: enabled debug flags: memstat gpg:
> > searching for "michaelkintzios@gmail.com" from hkp server
> > keys.gnupg.net (1)	Michael Kintzios (Mick)
> > <michaelkintzios@gmail.com> 1024 bit DSA key 792968B6, created:
> > 2009-04-25 ... [snip]
> > 
> > 
> > While Hinnerk's key is not found:
> > 
> > 
> > $ /usr/bin/gpg2 --keyserver hkp://keys.gnupg.net --search-keys
> > "h.v.bruinehsen@fu-berlin.de" gpg: enabled debug flags: memstat
> > gpg: searching for "h.v.bruinehsen@fu-berlin.de" from hkp server
> > keys.gnupg.net gpg: key "h.v.bruinehsen@fu-berlin.de" not found on
> > keyserver
> > 
> > 
> > Have you specified a keyserver to be used as a default in your
> > setup?  I use hkp://keys.gnupg.net which operates a round robin
> > function on each connection so as to not over-burden individual
> > servers.
> 
> It seems like the 'Upload key' function of my enigmail doesn't work. I
> uploaded the key manually and now I can find it.

Kewl, now it works fine:

$ /usr/bin/gpg2 --keyserver hkp://keys.gnupg.net --search-keys 
"h.v.bruinehsen@fu-berlin.de"
gpg: enabled debug flags: memstat
gpg: searching for "h.v.bruinehsen@fu-berlin.de" from hkp server 
keys.gnupg.net
(1)	Hinnerk van Bruinehsen <h.v.bruinehsen@fu-berlin.de>
	  2048 bit RSA key 8D16461C, created: 2011-11-10
Keys 1-1 of 1 for "h.v.bruinehsen@fu-berlin.de".  Enter number(s), N)ext, or 
Q)uit >
-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: (Was) Re: [gentoo-user] emerge --update behavior

[Michael Mol]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mick wrote:
> On Tuesday 03 Jan 2012 17:52:19 Hinnerk van Bruinehsen wrote:
>> On 03.01.2012 18:39, Mick wrote:
>>> On Tuesday 03 Jan 2012 16:18:20 Michael Mol wrote:
>>>> Mick, yours gives me the same error:
>>>> 
>>>> gpg command line and output: C:\Program Files 
>>>> (x86)\GNU\GnuPG\gpg.exe gpg: Signature made 01/03/12
>>>> 11:01:03 using DSA key ID 792968B6 gpg: Can't check
>>>> signature: public key not found
>>>> 
>>>> Though trying querying for 8D16461C or 792968B6 at 
>>>> pool.sks-keyservers.net or subkeys.pgp.net gives me "no key 
>>>> found" errors.
>>> 
>>> Ahh ... that's probably different then, because my public key
>>> has been knocking around for a while.
>>> 
>>> $ /usr/bin/gpg2 --keyserver hkp://keys.gnupg.net --search-keys 
>>> "michaelkintzios@gmail.com" gpg: enabled debug flags: memstat
>>> gpg: searching for "michaelkintzios@gmail.com" from hkp server 
>>> keys.gnupg.net (1)	Michael Kintzios (Mick) 
>>> <michaelkintzios@gmail.com> 1024 bit DSA key 792968B6,
>>> created: 2009-04-25 ... [snip]
>>> 
>>> 
>>> While Hinnerk's key is not found:
>>> 
>>> 
>>> $ /usr/bin/gpg2 --keyserver hkp://keys.gnupg.net --search-keys 
>>> "h.v.bruinehsen@fu-berlin.de" gpg: enabled debug flags:
>>> memstat gpg: searching for "h.v.bruinehsen@fu-berlin.de" from
>>> hkp server keys.gnupg.net gpg: key
>>> "h.v.bruinehsen@fu-berlin.de" not found on keyserver
>>> 
>>> 
>>> Have you specified a keyserver to be used as a default in your 
>>> setup?  I use hkp://keys.gnupg.net which operates a round
>>> robin function on each connection so as to not over-burden
>>> individual servers.
>> 
>> It seems like the 'Upload key' function of my enigmail doesn't
>> work. I uploaded the key manually and now I can find it.
> 
> Kewl, now it works fine:
> 
> $ /usr/bin/gpg2 --keyserver hkp://keys.gnupg.net --search-keys 
> "h.v.bruinehsen@fu-berlin.de" gpg: enabled debug flags: memstat 
> gpg: searching for "h.v.bruinehsen@fu-berlin.de" from hkp server 
> keys.gnupg.net (1)	Hinnerk van Bruinehsen
> <h.v.bruinehsen@fu-berlin.de> 2048 bit RSA key 8D16461C, created:
> 2011-11-10 Keys 1-1 of 1 for "h.v.bruinehsen@fu-berlin.de".  Enter
> number(s), N)ext, or Q)uit >

...and testing sending a signed message. Key uploaded manually, but no
idea how quickly it will propagate.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPA0c5AAoJEC/SB0LItoL+AnQIAJgoI5bshSkSuqPUOqTgD78t
domQfMztoFKNUgzVeQoCPmHgcFYFL8SuhtaARlUXDqPI+fDzbbfY+jGf2fjyAZOc
xqqptQVSfxXnuz+usuC3WdcsIHlt4PQjBG+7t8RIArIdE/UIUZlQSfYJTTZVUHBf
b4xM7aTCXcoE+FZIoZ0hnAQUyT/+rXBsK4a01tLK7Qt7dmgfhffuOBbHx215WtW3
6Qo9SEjknF8w7v/aLcGw6EI+576R8oRCVoDrF/UFCOx0mKxh4myClQMunmh5y7Zs
C4QjlGTEMayIqoJsQQGBWO9DmEdRCxgPtataINb6WBuT7FMq1EQfMtCnPl1fdAo=
=oyky
-----END PGP SIGNATURE-----

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

[Walter Dnes]

On Tue, Jan 03, 2012 at 09:46:42AM +0200, Alan McKinnon wrote

> So your actual problem is that you relied on an arbitrary behaviour of
> portage from the days when the standard was "whatever portage does
> today" and you are unhappy because for you that is now broken.
> 
> But no-one ever promised you that behaviour in a stable API.

http://www.catb.org/~esr/writings/taoup/html/ch01s06.html#id2878339

> Rule of Least Surprise: In interface design, always do the least
> surprising thing.
> 
> (This is also widely known as the Principle of Least Astonishment.)

-- 
Walter Dnes <waltdnes@waltdnes.org>

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

[Pandu Poluan]

[-- Attachment #1: Type: text/plain, Size: 814 bytes --]

On Jan 3, 2012 7:08 PM, "Neil Bothwick" <neil@digimed.co.uk> wrote:
>
> On Tue, 03 Jan 2012 06:49:45 -0500, Tanstaafl wrote:
>
> > Neil, is the use of sets fully documented somewhere? I don't recall
> > reading about them in the Handbook, but its been a while since I read
> > it (and don't remember if I ever did cover to cover)...
>
> I can't recall where I found the documentation, but you can create a set
> in /etc/portage/sets/ with one atom per line. Then emerge @setname to
> install the packages.
>
> I find them really useful. For example I have a @base set listing all the
> packages I want on a new install (tmux, gentoolkit, portage-utils etc) so
> I can copy it to a new install and emerge @base to make sure I have all
> the tools I normally use.
>

Now *that's* useful. Thanks for the idea!

Rgds,

[-- Attachment #2: Type: text/html, Size: 1036 bytes --]