Re: [gentoo-user] Cleaning redundant configuration files

2011-06-03 Thread Alan McKinnon
Apparently, though unproven, at 00:45 on Friday 03 June 2011, Volker Armin 
Hemmann did opine thusly:

 NEVER remove user created data

That one sentence sums up this entire thread beautifully.

Thank you for saying that.


-- 
alan dot mckinnon at gmail dot com



Re: [gentoo-user] Cleaning redundant configuration files

2011-06-03 Thread Indi
On Fri, Jun 03, 2011 at 02:00:01AM +0200, Stroller wrote:
 
 Only saying since you asked - I've held my tongue for a long time.
 

The question that got you going was part of a control drama, not at all 
a sincere question -- think does this dress make me look fat? :) 

But really, personal stuff is OT and who cares, anyway?
Obnoxious people are everywhere on earth, it's all part of life's rich 
pageant. One thing though I've observed is that people who are extremely
arrogant and defensive like that are driven to be that way due to 
crippling insecurities, so ironically a bit of compassion may be indicated.

-- 
caveat utilitor
♫ ❤ ♫ ❤ ♫ ❤ ♫ ❤ 



Re: [gentoo-user] Cleaning redundant configuration files

2011-06-03 Thread David W Noon
On Fri, 03 Jun 2011 01:00:02 +0200, Volker Armin Hemmann wrote about
Re: [gentoo-user] Cleaning redundant configuration files:

There is a simple rule in computing:

NEVER remove user created data

That is utter rubbish.  Obsolete data can be dangerous, so once it's
genuinely obsolete it should be gone.

If that were true, why would it even be possible to delete data?

that also applies to config files.

And obsolete configuration files are even more likely to be dangerous
than general data.
-- 
Regards,

Dave  [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
dwn...@ntlworld.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*


signature.asc
Description: PGP signature


Re: [gentoo-user] Cleaning redundant configuration files

2011-06-03 Thread Bill Longman
On 06/03/2011 07:52 AM, David W Noon wrote:
 On Fri, 03 Jun 2011 01:00:02 +0200, Volker Armin Hemmann wrote about
 Re: [gentoo-user] Cleaning redundant configuration files:
 
 There is a simple rule in computing:

 NEVER remove user created data
 
 That is utter rubbish.  Obsolete data can be dangerous, so once it's
 genuinely obsolete it should be gone.

No, he doesn't mean in the general sense. He means it's never the
auspices of someone else to delete your user-created data.

Have we sufficiently beaten this dead horse?



Re: [gentoo-user] Cleaning redundant configuration files

2011-06-03 Thread Alan McKinnon
Apparently, though unproven, at 16:52 on Friday 03 June 2011, David W Noon did 
opine thusly:



 On Fri, 03 Jun 2011 01:00:02 +0200, Volker Armin Hemmann wrote about
 
 Re: [gentoo-user] Cleaning redundant configuration files:
 There is a simple rule in computing:
 
 NEVER remove user created data
 
 That is utter rubbish.  Obsolete data can be dangerous, so once it's
 genuinely obsolete it should be gone.

You are painting yourself into a corner. Why don't you just admit the obvious, 
that you are holding onto an untenable position?

And please stop inferring other context than what is there.

 If that were true, why would it even be possible to delete data?

Look at what the statement applies to - an automated tool running cleanup 
operations after itself. You have strawmanned it into applying universally, 
which is decidedly NOT what Volker communicated.

 that also applies to config files.
 
 And obsolete configuration files are even more likely to be dangerous
 than general data.

Prove it.


-- 
alan dot mckinnon at gmail dot com



Re: [gentoo-user] Cleaning redundant configuration files

2011-06-03 Thread David W Noon
On Fri, 03 Jun 2011 17:20:02 +0200, Bill Longman wrote about Re:
[gentoo-user] Cleaning redundant configuration files:

On 06/03/2011 07:52 AM, David W Noon wrote:
 On Fri, 03 Jun 2011 01:00:02 +0200, Volker Armin Hemmann wrote about
 Re: [gentoo-user] Cleaning redundant configuration files:
 
 There is a simple rule in computing:

 NEVER remove user created data
 
 That is utter rubbish.  Obsolete data can be dangerous, so once it's
 genuinely obsolete it should be gone.

No, he doesn't mean in the general sense. He means it's never the
auspices of someone else to delete your user-created data.

Well, it's the sysadmin who installs the packages; it's the sysadmin
who modifies the configuration files; it's the sysadmin who deletes the
packages.  There is no someone else, at least on my systems.

Have we sufficiently beaten this dead horse?

It stopped breathing a day or two back, so I guess so.
-- 
Regards,

Dave  [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
dwn...@ntlworld.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*


signature.asc
Description: PGP signature


Re: [gentoo-user] Cleaning redundant configuration files

2011-06-03 Thread Volker Armin Hemmann
On Friday 03 June 2011 15:52:25 David W Noon wrote:
 On Fri, 03 Jun 2011 01:00:02 +0200, Volker Armin Hemmann wrote about
 
 Re: [gentoo-user] Cleaning redundant configuration files:
 There is a simple rule in computing:
 
 NEVER remove user created data
 
 That is utter rubbish.  Obsolete data can be dangerous, so once it's
 genuinely obsolete it should be gone.
 

bullshit. The package manager has no way to know what user generated data is 
obsolete. All it knows that the file it installed was manipulated.

 If that were true, why would it even be possible to delete data?

because the user decides to delete the data. Not the machine. Not a package 
manager.

 
 that also applies to config files.
 
 And obsolete configuration files are even more likely to be dangerous
 than general data.

really? Please show me an example of.. say an undeleted pure-ftpd 
configuration has a bad influence on your system. 

It is your job as administrator to clean up config files. Because only you, 
the administrator know what files can be deleted, which files should be saved 
(even just for documentation) and which files must not be touched.

The package manager can not decide that.



Re: [gentoo-user] Cleaning redundant configuration files

2011-06-03 Thread Michael Orlitzky
Nobody wants portage to delete modified config files. Some people might
think they do, but they don't: they just don't know it yet.

See also: condoms, seatbelts.



Re: [gentoo-user] Cleaning redundant configuration files

2011-06-03 Thread Dale

David W Noon wrote:

On Fri, 03 Jun 2011 01:00:02 +0200, Volker Armin Hemmann wrote about
Re: [gentoo-user] Cleaning redundant configuration files:

   

There is a simple rule in computing:

NEVER remove user created data
 

That is utter rubbish.  Obsolete data can be dangerous, so once it's
genuinely obsolete it should be gone.

If that were true, why would it even be possible to delete data?

   

that also applies to config files.
 

And obsolete configuration files are even more likely to be dangerous
than general data.
   


I think the rubbish is in your post.  IF, big IF for a reason, the 
config file is obsolete, the user should know that and can delete it 
themselves.  Also, if a package is updated and it is such a huge update, 
the config tool is going to let the user know about the changes.  Let's 
see, openrc comes to mind on this one since it was recently done.  Some 
config files were moved, done away with and justs plain old changed.  In 
that case, portage told us what files could be deleted, what had to be 
changed and such.  .


I hope you realize that if the devs were to decide to do this that they 
would also listen to the users.  You seem to be the only one that wants 
config files deleted by default.  The devs are most likely to see it the 
same as we do because they have a clear understanding of what Gentoo is 
all about.  In case you need a reminder, the person responsible for 
administering their system sits in the chair.  Portage just helps the 
person in the chair.  As far as I know, portage has never deleted user 
data.  Anything that is changed by the user becomes user data and the 
user owns it from then on.   As some already know, I been using Gentoo 
since about 2003.  It's not like I am new here.  I don't recall portage 
ever deleting a users data, ever.


I like the idea of having the option to remove config files but NOT by 
default as you seem to suggest.  If you take this to the devs to have 
this added to portage's feature set, I would put in my $0.02 worth.  I 
would expect that they would have much more than $0.02 worth to add to 
the idea.  I feel requesting it as a default behavior would be the death 
of the whole idea.   Care to request it and see what happens?


Dale

:-)  :-)



Re: [gentoo-user] Cleaning redundant configuration files

2011-06-03 Thread Stroller

On 3 June 2011, at 16:54, Alan McKinnon wrote:
 ...
 Well, thank you for speaking your mind. Very few people do that.
 
 Is the issue now dealt with so we can move on?

I guess so. You asked, I answered. I don't think I've got anything else to say 
on the subject. Nuff respect to you for your calm response.

Stroller.
 


Re: [gentoo-user] Cleaning redundant configuration files

2011-06-02 Thread Indi
On Wed, Jun 01, 2011 at 11:47:35AM +0200, Alan McKinnon wrote:
 Apparently, though unproven, at 11:31 on Wednesday 01 June 2011, Indi did 
 opine thusly:
 
  On Wed, Jun 01, 2011 at 02:00:01AM +0200, Peter Humphrey wrote:
   Personally, I'd be livid if portage were to remove my carefully crafted
   work from time immemorial, without so much as a by-your-leave. Anyone
   who wants to delete his own work is free to do so, but the rest of us
   ought not to be required to suffer it.
  
  Doesn't matter to me, my longstanding rsync habit ensures there are
  always a couple of copies of my last known good configuration.
  Doesn't your carefully crafted work from time immemorial deserve
  rsync too? [cue rsync jingle]
  
  :)
 
 That's like saying that just because I have panel-beating skills and lots of 
 scrap metal in the back yard that it's perfectly OK for marauding gangs of 
 thugs to have at my car in the parking lots with baseball bats.
 

Comapring a simple rsync command with hard physical labor?
Nah...

-- 
caveat utilitor
♫ ❤ ♫ ❤ ♫ ❤ ♫ ❤ 



Re: [gentoo-user] Cleaning redundant configuration files

2011-06-02 Thread Indi
On Wed, Jun 01, 2011 at 04:30:02PM +0200, Mike Edenfield wrote:
 On 6/1/2011 5:47 AM, Alan McKinnon wrote:
  Apparently, though unproven, at 11:31 on Wednesday 01 June 2011, Indi did 
  opine thusly:
  
  On Wed, Jun 01, 2011 at 02:00:01AM +0200, Peter Humphrey wrote:
  Personally, I'd be livid if portage were to remove my carefully crafted
  work from time immemorial, without so much as a by-your-leave. Anyone
  who wants to delete his own work is free to do so, but the rest of us
  ought not to be required to suffer it.
 
  Doesn't matter to me, my longstanding rsync habit ensures there are
  always a couple of copies of my last known good configuration.
  Doesn't your carefully crafted work from time immemorial deserve
  rsync too? [cue rsync jingle]
 
  :)
  
  That's like saying that just because I have panel-beating skills and lots 
  of 
  scrap metal in the back yard that it's perfectly OK for marauding gangs of 
  thugs to have at my car in the parking lots with baseball bats.
 
 Best analogy ever.

Hardly, though it does have a lot of drama which is what matters to
some. :)

-- 
caveat utilitor
♫ ❤ ♫ ❤ ♫ ❤ ♫ ❤ 



Re: [gentoo-user] Cleaning redundant configuration files

2011-06-02 Thread Indi
On Wed, Jun 01, 2011 at 08:20:01PM +0200, Dale wrote:
 David W Noon wrote:
  On Wed, 01 Jun 2011 18:20:02 +0200, Neil Bothwick wrote about Re:
  [gentoo-user] Cleaning redundant configuration files:
 
 
  On Wed, 1 Jun 2011 15:57:58 +0100, David W Noon wrote:
   
  [snip]
 
  Remember: we are discussing the COMPLETE DELETION of a
  package, not an upgrade or rebuild.
 
  We are discussing unmerge behaviour, unmerging is part of the upgrade
  and rebuild processes.
   
  Now I see why we are talking/writing at cross purposes.
 
  What I am proposing I would apply only to -C or -c options on an emerge
  command, not the internal actions during an upgrade/rebuild.  I have
  stated that several times in this thread, so I thought I had made
  myself clear.
 
 
 Even if the -C option is used, I would still want it to be something 
 extra to remove config files.  As stated before, I sometimes emerge -C a 
 package then emerge it again.  I still want the config files to be left 
 alone tho.  I have also had to do this before for *B*lockers where 
 portage couldn't do it itself for whatever reason.
 
 I would think this would be a idea on this.  Do a emerge -C to get the 
 regular way and a emerge -CC to remove everything literally, including 
 config files.
 
 As someone else posted, I seriously doubt the devs will do this.  
 Possible but not likely.  I like the idea but still want it to be 
 something extra to get it and not the default for sure.
 

Like debian's --purge option to their apt-get remove command.
It seems reasonable. There've been times I'd have liked a simple 
inventory of all files relating to a package after unmerging it, 
like warning -- the following files are associated with [pkg] 
but will not be automatically removed due to having been modified.

-- 
caveat utilitor
♫ ❤ ♫ ❤ ♫ ❤ ♫ ❤ 



Re: [gentoo-user] Cleaning redundant configuration files

2011-06-02 Thread Neil Bothwick
On Thu, 2 Jun 2011 09:18:36 -0400, Indi wrote:

  There've been times I'd have liked a simple 
 inventory of all files relating to a package after unmerging it, 
 like warning -- the following files are associated with [pkg] 
 but will not be automatically removed due to having been modified.

That sounds like a good idea for a default inclusion in pkg_postrm() so
the information would end up wherever you sent elog messages.


-- 
Neil Bothwick

Okay, who put a stop payment on my reality check?


signature.asc
Description: PGP signature


Re: [gentoo-user] Cleaning redundant configuration files

2011-06-02 Thread Alan McKinnon
Apparently, though unproven, at 15:09 on Thursday 02 June 2011, Indi did opine 
thusly:

 On Wed, Jun 01, 2011 at 04:30:02PM +0200, Mike Edenfield wrote:
  On 6/1/2011 5:47 AM, Alan McKinnon wrote:
   Apparently, though unproven, at 11:31 on Wednesday 01 June 2011, Indi
   did
   
   opine thusly:
   On Wed, Jun 01, 2011 at 02:00:01AM +0200, Peter Humphrey wrote:
   Personally, I'd be livid if portage were to remove my carefully
   crafted work from time immemorial, without so much as a
   by-your-leave. Anyone who wants to delete his own work is free to do
   so, but the rest of us ought not to be required to suffer it.
   
   Doesn't matter to me, my longstanding rsync habit ensures there are
   always a couple of copies of my last known good configuration.
   Doesn't your carefully crafted work from time immemorial deserve
   rsync too? [cue rsync jingle]
   
   :)
   
   That's like saying that just because I have panel-beating skills and
   lots of scrap metal in the back yard that it's perfectly OK for
   marauding gangs of thugs to have at my car in the parking lots with
   baseball bats.
  
  Best analogy ever.
 
 Hardly, though it does have a lot of drama which is what matters to
 some. :)

Actually it's quite relevant.

Just because I have and can use rsync to undo damage done by dubious features 
of portage is not a valid reason for portage to have dubious features. Which 
explains why portage by and large does not have dubious features.

So it's a good analogy, differing only in degree of devastation.


-- 
alan dot mckinnon at gmail dot com



Re: [gentoo-user] Cleaning redundant configuration files

2011-06-02 Thread Doug Hunley
On Thu, Jun 2, 2011 at 10:22, Neil Bothwick n...@digimed.co.uk wrote:
 On Thu, 2 Jun 2011 09:18:36 -0400, Indi wrote:

  There've been times I'd have liked a simple
 inventory of all files relating to a package after unmerging it,
 like warning -- the following files are associated with [pkg]
 but will not be automatically removed due to having been modified.

 That sounds like a good idea for a default inclusion in pkg_postrm() so
 the information would end up wherever you sent elog messages.

+1 to this. I'd find that very handy.



Re: [gentoo-user] Cleaning redundant configuration files

2011-06-02 Thread Alan McKinnon
Apparently, though unproven, at 15:05 on Thursday 02 June 2011, Indi did opine 
thusly:

  scrap metal in the back yard that it's perfectly OK for marauding gangs
  of  thugs to have at my car in the parking lots with baseball bats.
 
  
 
 Comapring a simple rsync command with hard physical labor?

Dude{,ss}

What exactly is your problem with me?

I get many replies from you with these little barbs in them. You do not do 
that to anyone else.

If you think I'm a juvenile wanker, a jerk or someone in possession of a 
miniscule penis, then come right out and say so. Get it out in the open so it 
can go away and we can move on.


-- 
alan dot mckinnon at gmail dot com



Re: [gentoo-user] Cleaning redundant configuration files

2011-06-02 Thread Indi
On Thu, Jun 02, 2011 at 04:50:02PM +0200, Alan McKinnon wrote:
 Apparently, though unproven, at 15:09 on Thursday 02 June 2011, Indi did 
 opine 
 thusly:
 
  On Wed, Jun 01, 2011 at 04:30:02PM +0200, Mike Edenfield wrote:
   On 6/1/2011 5:47 AM, Alan McKinnon wrote:
Apparently, though unproven, at 11:31 on Wednesday 01 June 2011, Indi
did

opine thusly:
On Wed, Jun 01, 2011 at 02:00:01AM +0200, Peter Humphrey wrote:
Personally, I'd be livid if portage were to remove my carefully
crafted work from time immemorial, without so much as a
by-your-leave. Anyone who wants to delete his own work is free to do
so, but the rest of us ought not to be required to suffer it.

Doesn't matter to me, my longstanding rsync habit ensures there are
always a couple of copies of my last known good configuration.
Doesn't your carefully crafted work from time immemorial deserve
rsync too? [cue rsync jingle]

:)

That's like saying that just because I have panel-beating skills and
lots of scrap metal in the back yard that it's perfectly OK for
marauding gangs of thugs to have at my car in the parking lots with
baseball bats.
   
   Best analogy ever.
  
  Hardly, though it does have a lot of drama which is what matters to
  some. :)
 
 Actually it's quite relevant.
 
 Just because I have and can use rsync to undo damage done by dubious features 
 of portage is not a valid reason for portage to have dubious features. Which 
 explains why portage by and large does not have dubious features.
 
 So it's a good analogy, differing only in degree of devastation.
 

OK, if you say so.
I guess the subject doesn't have the emotional charge for me it does for
some. My point was pretty much makes no difference to me, long as I
know what to expect and how it works.

-- 
caveat utilitor
♫ ❤ ♫ ❤ ♫ ❤ ♫ ❤ 



Re: [gentoo-user] Cleaning redundant configuration files

2011-06-02 Thread David W Noon
On Thu, 02 Jun 2011 01:10:02 +0200, Alan McKinnon wrote about Re:
[gentoo-user] Cleaning redundant configuration files:

Apparently, though unproven, at 17:52 on Wednesday 01 June 2011, David
W Noon did opine thusly:
 On Wed, 01 Jun 2011 17:20:03 +0200, Alan McKinnon wrote about Re:
[snip]
 Your suggestion runs counter to the general philosophy that runs
 through Gentoo.
 
 In what way?  Since it would be an option, it would not diminish the
 control the user has over the machine.

If you can provide solid examples where standard Gentoo tools do this 
operation:

I don't know what this is, but I'm just going to delete/modify/change
it anyway

My issue is with your I don't know what this is, application.

Portage knows exactly what a given configuration file is, as the
package still owns the file.  The way it detects that the file has been
customized is that the MD5 checksum and/or file size differ from that
stored in the package manifest.

As an example, here is the manifest for sys-apps/mlocate:


dir /var
dir /var/lib
dir /var/lib/mlocate
obj /var/lib/mlocate/.keep_sys-apps_mlocate-0
d41d8cd98f00b204e9800998ecf8427e 1299760691 dir /etc
obj /etc/mlocate-cron.conf 61bf658fd1bd59e3d76a0508ce6a2c18 1299760691
dir /etc/cron.daily
obj /etc/cron.daily/mlocate 8a823735ba1c795530153b697a6eb4a6 1299760691
obj /etc/updatedb.conf 3b5668efaeb3c8189f0a083c5c0b0446 1299760691
dir /usr
dir /usr/share
dir /usr/share/locale
dir /usr/share/locale/en_GB
dir /usr/share/locale/en_GB/LC_MESSAGES
obj /usr/share/locale/en_GB/LC_MESSAGES/mlocate.mo
ac21511ec0a7ee5132efdcec3bba6972 1299760690 dir /usr/share/doc
dir /usr/share/doc/mlocate-0.23.1-r1
obj /usr/share/doc/mlocate-0.23.1-r1/AUTHORS.bz2
5c58a4a7b231e958659b3484a7ffc396 1299760691
obj /usr/share/doc/mlocate-0.23.1-r1/NEWS.bz2
dc349b5ff8a89aea3240d72cd5b1f003 1299760691
obj /usr/share/doc/mlocate-0.23.1-r1/ChangeLog.bz2
79d003105968fc22b09dffbeaf9fcae1 1299760691
obj /usr/share/doc/mlocate-0.23.1-r1/README.bz2
5e6b8cb236de3297976d1a44d86a8b36 1299760691 dir /usr/share/man
dir /usr/share/man/man1 obj /usr/share/man/man1/locate.1.bz2
88c757c7fb1eb260dd60fe8499d1d645 1299760691 dir /usr/share/man/man8
obj /usr/share/man/man8/updatedb.8.bz2 6aa33ce09341bf9a8f10e3ec8fe0548b
1299760691 dir /usr/share/man/man5
obj /usr/share/man/man5/mlocate.db.5.bz2
b626526695f7b1116807c33f4a370a7e 1299760691
obj /usr/share/man/man5/updatedb.conf.5.bz2
e5c7b82b2eb7bbce7ce1ce0b49ca1afd 1299760691 dir /usr/bin
obj /usr/bin/locate c16d67deca5064ea2fec1e2bb670f75f 1299760692
obj /usr/bin/updatedb 15884d54ea11e1a00b5f640ae49e93d8 1299760692


[For those who don't know, this file is
named /var/db/pkg/sys-apps/mlocate/CONTENTS.  All packages have a
CONTENTS file, as that is how Portage keeps track of file ownership by
packages.]

Now, nearly everybody modifies /etc/updatedb.conf.  This does not
remove that name from mlocate's manifest.  So, Portage knows precisely
to which package the file belongs.  Hence I think your assertion of I
don't know what this is, is specious.

If I then do emerge -C mlocate and delete the package, my customized
version of /etc/updatedb.conf will remain on the root partition, in
spite of the fact that it is now useless.  During that emerge
operation, Portage knows that the file belongs to the package being
removed, but because the MD5 differs from that in the manifest it does
not delete the file.  I would prefer that it did delete the file, at
least in response to a run-time option.
-- 
Regards,

Dave  [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
dwn...@ntlworld.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*


signature.asc
Description: PGP signature


Re: [gentoo-user] Cleaning redundant configuration files

2011-06-02 Thread Indi
On Thu, Jun 02, 2011 at 05:00:03PM +0200, Alan McKinnon wrote:
 Apparently, though unproven, at 15:05 on Thursday 02 June 2011, Indi did 
 opine 
 thusly:
 
   scrap metal in the back yard that it's perfectly OK for marauding gangs
   of  thugs to have at my car in the parking lots with baseball bats.
  
   
  
  Comapring a simple rsync command with hard physical labor?
 
 Dude{,ss}
 
 What exactly is your problem with me?
 
 I get many replies from you with these little barbs in them. You do not do 
 that to anyone else.
 
 If you think I'm a juvenile wanker, a jerk or someone in possession of a 
 miniscule penis, then come right out and say so. Get it out in the open so it 
 can go away and we can move on.
 

You are reading something I didn't write.
It's absurd to equate the issuing of a command with rebuilding a wrecked
car. That's the only thing I was saying. BTW, growing up my dad rebuilt
cars from wrecks, so maybe you just don't realize the incredible amount
of work you're comparing to typing a text string?

Sorry if you thought otherwise.

-- 
caveat utilitor
♫ ❤ ♫ ❤ ♫ ❤ ♫ ❤ 



Re: [gentoo-user] Cleaning redundant configuration files

2011-06-02 Thread Neil Bothwick
On Thu, 2 Jun 2011 17:26:44 +0100, David W Noon wrote:

 My issue is with your I don't know what this is, application.
 
 Portage knows exactly what a given configuration file is, as the
 package still owns the file.  The way it detects that the file has been
 customized is that the MD5 checksum and/or file size differ from that
 stored in the package manifest.
 
 As an example, here is the manifest for sys-apps/mlocate:

[snip]
 Now, nearly everybody modifies /etc/updatedb.conf.  This does not
 remove that name from mlocate's manifest.  So, Portage knows precisely
 to which package the file belongs.  Hence I think your assertion of I
 don't know what this is, is specious.

You have picked an excellent example, because mlocate is not the package
that owns or has owned /etc/updatedb.conf, slocate does too. If the
checksum does not match, portage does not know with certainty that the
file belongs to that package, all it knows is that the file has a name in
common with a file installed by that package.

In fact, it is most likely that that file was never owned by mlocate, on
most systems it would have been installed by slocate, modified by the
user, left in place when slocate was unmerged and not overwritten when
mlocate was installed. So you have a file that was installed by one
package that you want another package to uninstall.

There are other examples of different packages, usually doing the same
job and mutually blocking, that share config file names. That is why
portage cannot sanely remove a file that just happens to have the same
name as a file that may have been installed by the package in question,
even though it does not have the same contents as that package's version
of the file.


-- 
Neil Bothwick

Top Oxymorons Number 45: Resident alien


signature.asc
Description: PGP signature


Re: [gentoo-user] Cleaning redundant configuration files

2011-06-02 Thread Alan McKinnon
Apparently, though unproven, at 18:26 on Thursday 02 June 2011, David W Noon 
did opine thusly:

 On Thu, 02 Jun 2011 01:10:02 +0200, Alan McKinnon wrote about Re:
 
 [gentoo-user] Cleaning redundant configuration files:
 Apparently, though unproven, at 17:52 on Wednesday 01 June 2011, David
 
 W Noon did opine thusly:
  On Wed, 01 Jun 2011 17:20:03 +0200, Alan McKinnon wrote about Re:
 [snip]
 
  Your suggestion runs counter to the general philosophy that runs
  through Gentoo.
  
  In what way?  Since it would be an option, it would not diminish the
  control the user has over the machine.
 
 If you can provide solid examples where standard Gentoo tools do this
 operation:
 
 I don't know what this is, but I'm just going to delete/modify/change
 it anyway
 
 My issue is with your I don't know what this is, application.
 
 Portage knows exactly what a given configuration file is, as the
 package still owns the file.  The way it detects that the file has been
 customized is that the MD5 checksum and/or file size differ from that
 stored in the package manifest.

Please look a little deeper and try to understand what I am saying, your 
response is bordering closely on being a strawman.

When I used the word this, I meant the file itself, it's contents and all 
known metadata about the file. Which is a lot more information than the mere 
existence of the file itself.
 
 As an example, here is the manifest for sys-apps/mlocate:

[snip file list]

 [For those who don't know, this file is
 named /var/db/pkg/sys-apps/mlocate/CONTENTS.  All packages have a
 CONTENTS file, as that is how Portage keeps track of file ownership by
 packages.]
 
 Now, nearly everybody modifies /etc/updatedb.conf.  This does not
 remove that name from mlocate's manifest.  So, Portage knows precisely
 to which package the file belongs.  Hence I think your assertion of I
 don't know what this is, is specious.

Of course portage knows *what* the file is, it recorded the fact that it 
installed the file. It could even know what the *changed content* of the file 
is, that is mere data.

What it doesn't know is what the changed content means, because that is 
information, not data, and portage is software (by definition it is stupid).

With an unmerge, portage is confronted with a changed file. It has no idea 
what information the changes mean, not even differences consisting only of 
whitespace (some config files are sensitive to whitespace).

Realize that a deleted file is gone, all information in it is removed and in 
all likelihood cannot be retrieved (devs cannot assume that users are backing 
up files, and it has never been a documented requirement anyway to do so). So 
even in your example, portage really does not know what this is, and does 
not delete it.

 
 If I then do emerge -C mlocate and delete the package, my customized
 version of /etc/updatedb.conf will remain on the root partition, in
 spite of the fact that it is now useless.

Says whom?

Why do you assume it is useless? It may well be you on your machine for the 
next 5 minutes as the code that uses it is missing, but is it always going to 
be useless? Can you guarantee that for all users and all instances for ever 
and ever?

 During that emerge
 operation, Portage knows that the file belongs to the package being
 removed, but because the MD5 differs from that in the manifest it does
 not delete the file.  I would prefer that it did delete the file, at
 least in response to a run-time option.

All that portage knows is that the package is being unmerged, it does not know 
why - again, that is information and you have no way to tell portage *why* you 
want the package unmerged, only *that* you do.

Your last sentence implies you'd prefer it if portage deleted the file by 
default, but would be happy to have it done as an option. Do you comprehend 
how dangerous that is? Do you realise how easy it is to, for example, unmerge 
a package to resolve blockers and forget that portage will nuke your configs?

Are you really willing to take that chance?

-- 
alan dot mckinnon at gmail dot com



Re: [gentoo-user] Cleaning redundant configuration files

2011-06-02 Thread Mick
On Thursday 02 Jun 2011 15:40:17 Doug Hunley wrote:
 On Thu, Jun 2, 2011 at 10:22, Neil Bothwick n...@digimed.co.uk wrote:
  On Thu, 2 Jun 2011 09:18:36 -0400, Indi wrote:
   There've been times I'd have liked a simple
  inventory of all files relating to a package after unmerging it,
  like warning -- the following files are associated with [pkg]
  but will not be automatically removed due to having been modified.
  
  That sounds like a good idea for a default inclusion in pkg_postrm() so
  the information would end up wherever you sent elog messages.
 
 +1 to this. I'd find that very handy.

+1

It'll be a nice check of a failing memory (did I do what?!) or finding out if 
you'd been hacked ...  :))
-- 
Regards,
Mick


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-user] Cleaning redundant configuration files

2011-06-02 Thread David W Noon
On Thu, 02 Jun 2011 19:00:02 +0200, Neil Bothwick wrote about Re:
[gentoo-user] Cleaning redundant configuration files:

On Thu, 2 Jun 2011 17:26:44 +0100, David W Noon wrote:
[snip]
 Now, nearly everybody modifies /etc/updatedb.conf.  This does not
 remove that name from mlocate's manifest.  So, Portage knows
 precisely to which package the file belongs.  Hence I think your
 assertion of I don't know what this is, is specious.

You have picked an excellent example, because mlocate is not the
package that owns or has owned /etc/updatedb.conf, slocate does too.

Wrong.

One can (well, could) only have one of slocate and mlocate installed at
any given time.  Whichever one is installed owns /etc/updatedb.conf,
unless both have been unmerged and the file is a remnant, but it cannot
be owned by both.  Moreover, slocate has been deleted from the main
Portage tree, so it doesn't own anything any more.
-- 
Regards,

Dave  [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
dwn...@ntlworld.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*


signature.asc
Description: PGP signature


Re: [gentoo-user] Cleaning redundant configuration files

2011-06-02 Thread Volker Armin Hemmann
On Wednesday 01 June 2011 19:53:32 David W Noon wrote:
 On Wed, 01 Jun 2011 20:20:02 +0200, Volker Armin Hemmann wrote about
 
 Re: [gentoo-user] Cleaning redundant configuration files:
 On Wednesday 01 June 2011 15:57:58 David W Noon wrote:
 [snip]
 
  I called it an annoyance.  Having to clean up obsolete
  configuration files is just that, unless you can offer a better term.
 
 so - what happens when you uninstall a package to cleanly install it
 again?
 
 Happens from time to time - and I seriously would not want to see the
 carefully personalized config file be moved to the big blue electron
 pool in heaven.
 
 That's easy: if you know you are going to reinstall after deleting,
 just take a backup copy of those files you have modified, which is
 usually only the one configuration file.  After the reinstallation,
 restore from your backup.
 
 Alternatively, you can switch the suggested option to off, either on
 the command line or in /etc/make.conf.
 
 This is a fairly rare occurrence, and it should be planned -- including
 the making of a backup.

no, usually something like this happens at 2:30 am without planning because 
the last -uD world fucked everything up and you have tried all other options 
in the last hours. And losing your pure-ftpd user database because of a 
mistype in portage options is a complete nightmare.

There is a simple rule in computing:

NEVER remove user created data

that also applies to config files.

There are ways to check if a file is still needed by something in your system. 
But portage has no business touching something that is not in the same state 
as it was when it was installed.



Re: [gentoo-user] Cleaning redundant configuration files

2011-06-02 Thread Volker Armin Hemmann
On Thursday 02 June 2011 21:28:48 David W Noon wrote:
 On Thu, 02 Jun 2011 19:00:02 +0200, Neil Bothwick wrote about Re:
 
 [gentoo-user] Cleaning redundant configuration files:
 On Thu, 2 Jun 2011 17:26:44 +0100, David W Noon wrote:
 [snip]
 
  Now, nearly everybody modifies /etc/updatedb.conf.  This does not
  remove that name from mlocate's manifest.  So, Portage knows
  precisely to which package the file belongs.  Hence I think your
  assertion of I don't know what this is, is specious.
 
 You have picked an excellent example, because mlocate is not the
 package that owns or has owned /etc/updatedb.conf, slocate does too.
 
 Wrong.
 
 One can (well, could) only have one of slocate and mlocate installed at
 any given time.  Whichever one is installed owns /etc/updatedb.conf,
 unless both have been unmerged and the file is a remnant, but it cannot
 be owned by both.  Moreover, slocate has been deleted from the main
 Portage tree, so it doesn't own anything any more.

and it is still installed on some systems. And there is no reason to remove it 
on uninstalling slocate if you plan to install mlocate.

Don't touch things you did not install.

Is the only sane rule for packet manager.



Re: [gentoo-user] Cleaning redundant configuration files

2011-06-02 Thread Stroller

On 2 Jun 2011, at 15:48, Alan McKinnon wrote:
 
 What exactly is your problem with me?

You really have to ask?

 If you think I'm a juvenile wanker, a jerk or someone in possession of a 
 miniscule penis, then come right out and say so. Get it out in the open so it 
 can go away and we can move on.

Arrogant asshole is the term I would use to describe you.

You're right 99% of the time, but that's not much help (IMO) if you're pissing 
people off when being so.

On the (admittedly rare) occasions on which you're factually wrong, you don't 
admit it, fess up and take it on the head. You were factually wrong once or 
twice a while back and I thought about pulling you up on it, but I thought 
new, it ain't worth the effort, he won't accept it. On one of those occasions 
I wouldn't have been surprised if you discouraged the OP (who was a newcomer or 
an irregular poster here) from coming back here for help.

When it comes to matters of opinion, in which there is room for debate and 
disagreement, you're still aggressive in your assertions. It *is* a matter of 
opinion, yet you always claim to be right. I wouldn't blame Indi or anyone 
for being offended by the way you write. You come across as totally 
self-righteous. 

I thought you were aware of this. You frequently boast about what a hard-man, 
wizened old Unix guru you are, and how my bosses put up with my shit because 
I'm the best c c. I would never work with you, and I would take satisfaction 
in the opportunity to snub you.

Of course it is better to be right than to be wrong, but if you can express 
yourself in a humble manner then it sets you up safe for when you do fall over, 
something which happens to everybody.

I honestly didn't think you cared what most people think of you, although you 
do act very matey with one or two of your favorite buddies sometimes, like this 
list is a boys club that you share them.  

Only saying since you asked - I've held my tongue for a long time.

Stroller.




Re: [gentoo-user] Cleaning redundant configuration files

2011-06-02 Thread Neil Bothwick
On Thu, 2 Jun 2011 21:28:48 +0100, David W Noon wrote:

 You have picked an excellent example, because mlocate is not the
 package that owns or has owned /etc/updatedb.conf, slocate does too.  
 
 Wrong.
 
 One can (well, could) only have one of slocate and mlocate installed at
 any given time.  Whichever one is installed owns /etc/updatedb.conf,

Even if that package did not install the file? Are you now saying that
packages can assume ownership of files they did not install?

You may need to read the salient parts of my post that you chose not to
quote to understand this.


-- 
Neil Bothwick

Cross-country skiing is great in small countries.


signature.asc
Description: PGP signature


Re: [gentoo-user] Cleaning redundant configuration files

2011-06-02 Thread Adam Carter

 On 2 Jun 2011, at 15:48, Alan McKinnon wrote:
 
  What exactly is your problem with me?

 You really have to ask?

  If you think I'm a juvenile wanker, a jerk or someone in possession of a
  miniscule penis, then come right out and say so. Get it out in the open
 so it
  can go away and we can move on.

 Arrogant asshole is the term I would use to describe you.

 snip
Lulz. Its getting spicy in here.

Ooh! Stroller, please do Volker now! :) I'll get some popcorn.

(Sorry Volker)


Re: [gentoo-user] Cleaning redundant configuration files

2011-06-02 Thread Volker Armin Hemmann
On Friday 03 June 2011 11:13:48 Adam Carter wrote:
  On 2 Jun 2011, at 15:48, Alan McKinnon wrote:
   What exactly is your problem with me?
  
  You really have to ask?
  
   If you think I'm a juvenile wanker, a jerk or someone in possession
   of a miniscule penis, then come right out and say so. Get it out in
   the open
  
  so it
  
   can go away and we can move on.
  
  Arrogant asshole is the term I would use to describe you.
  
  snip
 
 Lulz. Its getting spicy in here.
 
 Ooh! Stroller, please do Volker now! :) I'll get some popcorn.
 
 (Sorry Volker)

whatever makes your hollow three dimensional body buoyance



Re: [gentoo-user] Cleaning redundant configuration files

2011-06-01 Thread Alan McKinnon
Apparently, though unproven, at 01:48 on Wednesday 01 June 2011, Peter 
Humphrey did opine thusly:

  It's quite simple logic... If a file is modified, it is no longer the
  file portage installed, so portage does not uninstall it. If anything,
  the problem is that the logic used by portage is too simple.
 
 I don't think it's too simple. It seems exactly right for the task to me: 
 clear, predictable and easily understood.

And completely consistent with the philosophy of Gentoo, where the user is in 
complete control and must make the hard decisions.

-- 
alan dot mckinnon at gmail dot com



Re: [gentoo-user] Cleaning redundant configuration files

2011-06-01 Thread Neil Bothwick
On Wed, 1 Jun 2011 00:48:01 +0100, Peter Humphrey wrote:

  It's quite simple logic... If a file is modified, it is no longer the
  file portage installed, so portage does not uninstall it. If
  anything, the problem is that the logic used by portage is too
  simple.  
 
 I don't think it's too simple. It seems exactly right for the task to
 me: clear, predictable and easily understood.

The only time it failed to be that, IMO, was when a GCC update forced
wholesale modification of .la files, which were then left because they no
longer belonged to a package. I believe this no longer happens.

 Personally, I'd be livid if portage were to remove my carefully crafted
 work from time immemorial, without so much as a by-your-leave.

I get the impression that livid is the polite version ;-)


-- 
Neil Bothwick

WinErr 01B: Illegal error - You are not allowed to get this error.
Next time you will get a penalty for that.


signature.asc
Description: PGP signature


Re: [gentoo-user] Cleaning redundant configuration files

2011-06-01 Thread Indi
On Wed, Jun 01, 2011 at 02:00:01AM +0200, Peter Humphrey wrote:
 
 Personally, I'd be livid if portage were to remove my carefully crafted work 
 from time immemorial, without so much as a by-your-leave. Anyone who wants 
 to delete his own work is free to do so, but the rest of us ought not to be 
 required to suffer it.
 

Doesn't matter to me, my longstanding rsync habit ensures there are
always a couple of copies of my last known good configuration.
Doesn't your carefully crafted work from time immemorial deserve 
rsync too? [cue rsync jingle]
:)

-- 
caveat utilitor
♫ ❤ ♫ ❤ ♫ ❤ ♫ ❤ 



Re: [gentoo-user] Cleaning redundant configuration files

2011-06-01 Thread Alan McKinnon
Apparently, though unproven, at 11:31 on Wednesday 01 June 2011, Indi did 
opine thusly:

 On Wed, Jun 01, 2011 at 02:00:01AM +0200, Peter Humphrey wrote:
  Personally, I'd be livid if portage were to remove my carefully crafted
  work from time immemorial, without so much as a by-your-leave. Anyone
  who wants to delete his own work is free to do so, but the rest of us
  ought not to be required to suffer it.
 
 Doesn't matter to me, my longstanding rsync habit ensures there are
 always a couple of copies of my last known good configuration.
 Doesn't your carefully crafted work from time immemorial deserve
 rsync too? [cue rsync jingle]
 
 :)

That's like saying that just because I have panel-beating skills and lots of 
scrap metal in the back yard that it's perfectly OK for marauding gangs of 
thugs to have at my car in the parking lots with baseball bats.


-- 
alan dot mckinnon at gmail dot com



Re: [gentoo-user] Cleaning redundant configuration files

2011-06-01 Thread Mike Edenfield
On 6/1/2011 5:47 AM, Alan McKinnon wrote:
 Apparently, though unproven, at 11:31 on Wednesday 01 June 2011, Indi did 
 opine thusly:
 
 On Wed, Jun 01, 2011 at 02:00:01AM +0200, Peter Humphrey wrote:
 Personally, I'd be livid if portage were to remove my carefully crafted
 work from time immemorial, without so much as a by-your-leave. Anyone
 who wants to delete his own work is free to do so, but the rest of us
 ought not to be required to suffer it.

 Doesn't matter to me, my longstanding rsync habit ensures there are
 always a couple of copies of my last known good configuration.
 Doesn't your carefully crafted work from time immemorial deserve
 rsync too? [cue rsync jingle]

 :)
 
 That's like saying that just because I have panel-beating skills and lots of 
 scrap metal in the back yard that it's perfectly OK for marauding gangs of 
 thugs to have at my car in the parking lots with baseball bats.

Best analogy ever.



Re: [gentoo-user] Cleaning redundant configuration files

2011-06-01 Thread David W Noon
On Wed, 01 Jun 2011 01:20:02 +0200, Neil Bothwick wrote about Re:
[gentoo-user] Cleaning redundant configuration files:

On Tue, 31 May 2011 17:26:43 +0100, David W Noon wrote:

I'll trim my earlier quote down to the salient statement.

  It
  removes files that are still in the same state as when the
  package was emerged, but not those modified by the user.

 It doesn't remove *any* files that have been modified,
 
 Erm ... that's what I wrote, above. 

No it's not. You were referring to a special case of the general
statement I made.

I can see no material difference in the two statements in question,
unless you mean by the user is a special case.  By whom else would
files be modified externally to Portage?

[snip]
It's quite simple logic, whether or not you agree with it. If a file is
modified, it is no longer the file portage installed, so portage does
not uninstall it. If anything, the problem is that the logic used by
portage is too simple.

Yes, that is the way Portage currently works.  But ...

The contents of the file have been modified, but the file itself is
still owned by the package.  That's why etc-update, cfg-update, etc.,
check any new version of the file when the package is upgraded: the
file is still owned by the package.

So, when the package is to be removed, the file should also be removed
if the user has set an option so to do.

The place where the current logic could be considered valid is when the
file is an executable.  If an executable has been modified outside of
Portage then it is likely the user has installed a foreign package or a
home grown program.  One could argue that it is not the place of
Portage to remove these.

 To repeat myself: I do not see a customized configuration file as
 being any more important than a vanilla one.

A customised file contains an investment of the user's time, a generic
file does not. That investment may be small or great, but it is not
for portage to determine that value and remove the file without the
user's consent.

How much is that investment worth when the entire package is being
deleted?  Remember: we are discussing the COMPLETE DELETION of a
package, not an upgrade or rebuild.

[snip]
We agree on the usefulness of a purge-like option but not on the
desirability or otherwise of the current default behaviour

I called it an annoyance.  Having to clean up obsolete configuration
files is just that, unless you can offer a better term.
-- 
Regards,

Dave  [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
dwn...@ntlworld.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*


signature.asc
Description: PGP signature


Re: [gentoo-user] Cleaning redundant configuration files

2011-06-01 Thread David W Noon
On Wed, 01 Jun 2011 02:00:01 +0200, Peter Humphrey wrote about Re:
[gentoo-user] Cleaning redundant configuration files:

On Wednesday 01 June 2011 00:14:04 Neil Bothwick wrote:
[snip]
 A customised file contains an investment of the user's time, a
 generic file does not. That investment may be small or great, but it
 is not for portage to determine that value and remove the file
 without the user's consent.

Personally, I'd be livid if portage were to remove my carefully
crafted work from time immemorial, without so much as a by-your-leave.
Anyone who wants to delete his own work is free to do so, but the rest
of us ought not to be required to suffer it.

We are talking about the deletion of an entire package, not an upgrade
or rebuild.  Why do you want to keep customized configuration files
from a package that you are deleting?

Moreover, we are considering it as an on/off option.  You can set yours
to off if you want.
-- 
Regards,

Dave  [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
dwn...@ntlworld.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*


signature.asc
Description: PGP signature


Re: [gentoo-user] Cleaning redundant configuration files

2011-06-01 Thread Alan McKinnon
Apparently, though unproven, at 16:57 on Wednesday 01 June 2011, David W Noon 
did opine thusly:

 We agree on the usefulness of a purge-like option but not on the
 
 desirability or otherwise of the current default behaviour
 
 I called it an annoyance.  Having to clean up obsolete configuration
 files is just that, unless you can offer a better term.


Sounds like you want a --really-all suboption to -C

You could submit a feature request at b.g.o. but I feel the odds of getting it 
implemented (or even a working patch accepted at all) are rather low.

Your suggestion runs counter to the general philosophy that runs through 
Gentoo.

-- 
alan dot mckinnon at gmail dot com



Re: [gentoo-user] Cleaning redundant configuration files

2011-06-01 Thread David W Noon
On Wed, 01 Jun 2011 17:20:03 +0200, Alan McKinnon wrote about Re:
[gentoo-user] Cleaning redundant configuration files:

Sounds like you want a --really-all suboption to -C

Basically, yes.  I want it on -C and -c runs of emerge.

This means it would not be applicable to upgrade or rebuild runs, when
they do their removal of files from the previous version.  In fact,
rebuilds seldom remove files from the previous version, as it is the
same as the new version; only USE flag changes can mess with the
package manifest.

You could submit a feature request at b.g.o. but I feel the odds of
getting it implemented (or even a working patch accepted at all) are
rather low.

Your suggestion runs counter to the general philosophy that runs
through Gentoo.

In what way?  Since it would be an option, it would not diminish the
control the user has over the machine.
-- 
Regards,

Dave  [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
dwn...@ntlworld.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*


signature.asc
Description: PGP signature


Re: [gentoo-user] Cleaning redundant configuration files

2011-06-01 Thread Neil Bothwick
On Wed, 1 Jun 2011 15:57:58 +0100, David W Noon wrote:

 No it's not. You were referring to a special case of the general
 statement I made.
 
 I can see no material difference in the two statements in question,
 unless you mean by the user is a special case.  By whom else would
 files be modified externally to Portage?

I mean that your referring to config files is a special case, portage
won't remove any file from anywhere in the tree that has been modified.

 The contents of the file have been modified, but the file itself is
 still owned by the package.

That depends on your definition of ownership. The file is not the same
file that portage installed, so it can no longer claim ownership, that
is now down to whoever modified the file.

 That's why etc-update, cfg-update, etc.,
 check any new version of the file when the package is upgraded: the
 file is still owned by the package.

No, portage is checking whether a config file of the same name as the one
installed by the package exists. It doesn't care where the existing file
originated, only that it is in a CONFIG_PROTECTed directory and should
not be overwritten. etc-update and friends simply look for ._cfg* files.

 A customised file contains an investment of the user's time, a generic
 file does not. That investment may be small or great, but it is not
 for portage to determine that value and remove the file without the
 user's consent.
 
 How much is that investment worth when the entire package is being
 deleted?

That depends on whether the package will be installed again.

 Remember: we are discussing the COMPLETE DELETION of a
 package, not an upgrade or rebuild.

We are discussing unmerge behaviour, unmerging is part of the upgrade
and rebuild processes.
 
 We agree on the usefulness of a purge-like option but not on the
 desirability or otherwise of the current default behaviour
 
 I called it an annoyance.  Having to clean up obsolete configuration
 files is just that, unless you can offer a better term.

How about feature request waiting to be made?


-- 
Neil Bothwick

If at first you don't succeed, call in an airstrike.


signature.asc
Description: PGP signature


Re: [gentoo-user] Cleaning redundant configuration files

2011-06-01 Thread David W Noon
On Wed, 01 Jun 2011 18:20:02 +0200, Neil Bothwick wrote about Re:
[gentoo-user] Cleaning redundant configuration files:

On Wed, 1 Jun 2011 15:57:58 +0100, David W Noon wrote:
[snip]
 Remember: we are discussing the COMPLETE DELETION of a
 package, not an upgrade or rebuild.

We are discussing unmerge behaviour, unmerging is part of the upgrade
and rebuild processes.

Now I see why we are talking/writing at cross purposes.

What I am proposing I would apply only to -C or -c options on an emerge
command, not the internal actions during an upgrade/rebuild.  I have
stated that several times in this thread, so I thought I had made
myself clear.
-- 
Regards,

Dave  [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
dwn...@ntlworld.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*


signature.asc
Description: PGP signature


Re: [gentoo-user] Cleaning redundant configuration files

2011-06-01 Thread Dale

David W Noon wrote:

On Wed, 01 Jun 2011 18:20:02 +0200, Neil Bothwick wrote about Re:
[gentoo-user] Cleaning redundant configuration files:

   

On Wed, 1 Jun 2011 15:57:58 +0100, David W Noon wrote:
 

[snip]
   

Remember: we are discussing the COMPLETE DELETION of a
package, not an upgrade or rebuild.
   

We are discussing unmerge behaviour, unmerging is part of the upgrade
and rebuild processes.
 

Now I see why we are talking/writing at cross purposes.

What I am proposing I would apply only to -C or -c options on an emerge
command, not the internal actions during an upgrade/rebuild.  I have
stated that several times in this thread, so I thought I had made
myself clear.
   


Even if the -C option is used, I would still want it to be something 
extra to remove config files.  As stated before, I sometimes emerge -C a 
package then emerge it again.  I still want the config files to be left 
alone tho.  I have also had to do this before for *B*lockers where 
portage couldn't do it itself for whatever reason.


I would think this would be a idea on this.  Do a emerge -C to get the 
regular way and a emerge -CC to remove everything literally, including 
config files.


As someone else posted, I seriously doubt the devs will do this.  
Possible but not likely.  I like the idea but still want it to be 
something extra to get it and not the default for sure.


Dale

:-)  :-)



Re: [gentoo-user] Cleaning redundant configuration files

2011-06-01 Thread Todd Goodman
* David W Noon dwn...@ntlworld.com [110601 13:10]:
 On Wed, 01 Jun 2011 18:20:02 +0200, Neil Bothwick wrote about Re:
 [gentoo-user] Cleaning redundant configuration files:
 
 On Wed, 1 Jun 2011 15:57:58 +0100, David W Noon wrote:
 [snip]
  Remember: we are discussing the COMPLETE DELETION of a
  package, not an upgrade or rebuild.
 
 We are discussing unmerge behaviour, unmerging is part of the upgrade
 and rebuild processes.
 
 Now I see why we are talking/writing at cross purposes.
 
 What I am proposing I would apply only to -C or -c options on an emerge
 command, not the internal actions during an upgrade/rebuild.  I have
 stated that several times in this thread, so I thought I had made
 myself clear.
 -- 
 Regards,
 
 Dave  [RLU #314465]
 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
 dwn...@ntlworld.com (David W Noon)
 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

What you seem to ignore or miss in the discussion is that an
emerge -C is necessary at times during an upgrade and rebuild when package
dependencies are not perfect.

That said, having it configurable with the default being the current
operation seems flexible.

Todd



Re: [gentoo-user] Cleaning redundant configuration files

2011-06-01 Thread Volker Armin Hemmann
On Wednesday 01 June 2011 15:57:58 David W Noon wrote:
 On Wed, 01 Jun 2011 01:20:02 +0200, Neil Bothwick wrote about Re:
 
 [gentoo-user] Cleaning redundant configuration files:
 On Tue, 31 May 2011 17:26:43 +0100, David W Noon wrote:
 I'll trim my earlier quote down to the salient statement.
 
   It
   removes files that are still in the same state as when the
   package was emerged, but not those modified by the user.
  
  It doesn't remove *any* files that have been modified,
  
  Erm ... that's what I wrote, above.
 
 No it's not. You were referring to a special case of the general
 statement I made.
 
 I can see no material difference in the two statements in question,
 unless you mean by the user is a special case.  By whom else would
 files be modified externally to Portage?
 
 [snip]
 
 It's quite simple logic, whether or not you agree with it. If a file is
 modified, it is no longer the file portage installed, so portage does
 not uninstall it. If anything, the problem is that the logic used by
 portage is too simple.
 
 Yes, that is the way Portage currently works.  But ...
 
 The contents of the file have been modified, but the file itself is
 still owned by the package.  That's why etc-update, cfg-update, etc.,
 check any new version of the file when the package is upgraded: the
 file is still owned by the package.
 
 So, when the package is to be removed, the file should also be removed
 if the user has set an option so to do.
 
 The place where the current logic could be considered valid is when the
 file is an executable.  If an executable has been modified outside of
 Portage then it is likely the user has installed a foreign package or a
 home grown program.  One could argue that it is not the place of
 Portage to remove these.
 
  To repeat myself: I do not see a customized configuration file as
  being any more important than a vanilla one.
 
 A customised file contains an investment of the user's time, a generic
 file does not. That investment may be small or great, but it is not
 for portage to determine that value and remove the file without the
 user's consent.
 
 How much is that investment worth when the entire package is being
 deleted?  Remember: we are discussing the COMPLETE DELETION of a
 package, not an upgrade or rebuild.
 
 [snip]
 
 We agree on the usefulness of a purge-like option but not on the
 desirability or otherwise of the current default behaviour
 
 I called it an annoyance.  Having to clean up obsolete configuration
 files is just that, unless you can offer a better term.

so - what happens when you uninstall a package to cleanly install it again?

Happens from time to time - and I seriously would not want to see the 
carefully personalized config file be moved to the big blue electron pool in 
heaven.



Re: [gentoo-user] Cleaning redundant configuration files

2011-06-01 Thread David W Noon
On Wed, 01 Jun 2011 20:20:02 +0200, Volker Armin Hemmann wrote about
Re: [gentoo-user] Cleaning redundant configuration files:

On Wednesday 01 June 2011 15:57:58 David W Noon wrote:
[snip]
 I called it an annoyance.  Having to clean up obsolete
 configuration files is just that, unless you can offer a better term.

so - what happens when you uninstall a package to cleanly install it
again?

Happens from time to time - and I seriously would not want to see the 
carefully personalized config file be moved to the big blue electron
pool in heaven.

That's easy: if you know you are going to reinstall after deleting,
just take a backup copy of those files you have modified, which is
usually only the one configuration file.  After the reinstallation,
restore from your backup.

Alternatively, you can switch the suggested option to off, either on
the command line or in /etc/make.conf.

This is a fairly rare occurrence, and it should be planned -- including
the making of a backup.
-- 
Regards,

Dave  [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
dwn...@ntlworld.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*


signature.asc
Description: PGP signature


Re: [gentoo-user] Cleaning redundant configuration files

2011-06-01 Thread David W Noon
On Wed, 01 Jun 2011 20:20:01 +0200, Dale wrote about Re: [gentoo-user]
Cleaning redundant configuration files:

Even if the -C option is used, I would still want it to be something 
extra to remove config files.  As stated before, I sometimes emerge -C
a package then emerge it again.  I still want the config files to be
left alone tho.  I have also had to do this before for *B*lockers
where portage couldn't do it itself for whatever reason.

See my follow-up to Volker Armin Hemman on this.

I would think this would be a idea on this.  Do a emerge -C to get the 
regular way and a emerge -CC to remove everything literally, including 
config files.

I don't think that conforms to getopt() processing of the command line
options.  The single hyphen options normally have only a single letter.
But I suppose it could be treated as -C specified twice, which would be
equally mnemonic.
-- 
Regards,

Dave  [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
dwn...@ntlworld.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*


signature.asc
Description: PGP signature


Re: [gentoo-user] Cleaning redundant configuration files

2011-06-01 Thread David W Noon
On Wed, 01 Jun 2011 20:20:02 +0200, Todd Goodman wrote about Re:
[gentoo-user] Cleaning redundant configuration files:

What you seem to ignore or miss in the discussion is that an
emerge -C is necessary at times during an upgrade and rebuild when
package dependencies are not perfect.

See my follow-up to Volker Armin Hemmann on this.
-- 
Regards,

Dave  [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
dwn...@ntlworld.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*


signature.asc
Description: PGP signature


Re: [gentoo-user] Cleaning redundant configuration files

2011-06-01 Thread Todd Goodman
* David W Noon dwn...@ntlworld.com [110601 14:41]:
 On Wed, 01 Jun 2011 20:20:02 +0200, Todd Goodman wrote about Re:
 [gentoo-user] Cleaning redundant configuration files:
 
 What you seem to ignore or miss in the discussion is that an
 emerge -C is necessary at times during an upgrade and rebuild when
 package dependencies are not perfect.
 
 See my follow-up to Volker Armin Hemmann on this.
 -- 
 Regards,
 
 Dave  [RLU #314465]
 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
 dwn...@ntlworld.com (David W Noon)
 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

It's not a rare situation as you imply in that followup and
copying off/backing up and then restoring is a lot of busywork and
fraught with risk when the current situation works just fine, thank you
very much.

If the current situation is unacceptable to you, why not create a patch
and work to get it approved?

Please make it optional with the default being the existing behavior.

Todd



Re: [gentoo-user] Cleaning redundant configuration files

2011-06-01 Thread Dale

Todd Goodman wrote:

* David W Noondwn...@ntlworld.com  [110601 14:41]:
   

On Wed, 01 Jun 2011 20:20:02 +0200, Todd Goodman wrote about Re:
[gentoo-user] Cleaning redundant configuration files:

 

What you seem to ignore or miss in the discussion is that an
emerge -C is necessary at times during an upgrade and rebuild when
package dependencies are not perfect.
   

See my follow-up to Volker Armin Hemmann on this.
--
Regards,

Dave  [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
dwn...@ntlworld.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
 

It's not a rare situation as you imply in that followup and
copying off/backing up and then restoring is a lot of busywork and
fraught with risk when the current situation works just fine, thank you
very much.

If the current situation is unacceptable to you, why not create a patch
and work to get it approved?

Please make it optional with the default being the existing behavior.

Todd
   


+1.  Me, I like the idea but don't want it to be the default option.  If 
-CC won't work, then let it be some other option that can be added to 
-C.  I just know that the vast majority of the time, I do NOT want my 
config files deleted.  I wouldn't mind having the option available but 
just not the default.


Dale

:-)  :-)



Re: [gentoo-user] Cleaning redundant configuration files

2011-06-01 Thread Dale

David W Noon wrote:

That's easy: if you know you are going to reinstall after deleting,
just take a backup copy of those files you have modified, which is
usually only the one configuration file.  After the reinstallation,
restore from your backup.

Alternatively, you can switch the suggested option to off, either on
the command line or in /etc/make.conf.

This is a fairly rare occurrence, and it should be planned -- including
the making of a backup.
   


For me, wanting the config files removed is what is so very rare.  As to 
the backups, I make backups but not before every time I emerge/unmerge 
something.  Requiring users to do all that is worse than just deleting 
the config files manually.


Dale

:-)  :-)



Re: [gentoo-user] Cleaning redundant configuration files

2011-06-01 Thread Neil Bothwick
On Wed, 01 Jun 2011 13:06:23 -0500, Dale wrote:

 I would think this would be a idea on this.  Do a emerge -C to get the 
 regular way and a emerge -CC to remove everything literally, including 
 config files.

So a bit of keyboard bounce can nuke your configs? No thanks. I'd rather
have an explicit option, like --purge.


-- 
Neil Bothwick

Irritable? Who the bloody hell are you calling irritable?


signature.asc
Description: PGP signature


Re: [gentoo-user] Cleaning redundant configuration files

2011-06-01 Thread Alan McKinnon
Apparently, though unproven, at 17:52 on Wednesday 01 June 2011, David W Noon 
did opine thusly:

 On Wed, 01 Jun 2011 17:20:03 +0200, Alan McKinnon wrote about Re:
 
 [gentoo-user] Cleaning redundant configuration files:
 Sounds like you want a --really-all suboption to -C
 
 Basically, yes.  I want it on -C and -c runs of emerge.
 
 This means it would not be applicable to upgrade or rebuild runs, when
 they do their removal of files from the previous version.  In fact,
 rebuilds seldom remove files from the previous version, as it is the
 same as the new version; only USE flag changes can mess with the
 package manifest.
 
 You could submit a feature request at b.g.o. but I feel the odds of
 getting it implemented (or even a working patch accepted at all) are
 rather low.
 
 Your suggestion runs counter to the general philosophy that runs
 through Gentoo.
 
 In what way?  Since it would be an option, it would not diminish the
 control the user has over the machine.

If you can provide solid examples where standard Gentoo tools do this 
operation:

I don't know what this is, but I'm just going to delete/modify/change it 
anyway

then I'll concede you may have a point and be willing to discuss it further.


-- 
alan dot mckinnon at gmail dot com



Re: [gentoo-user] Cleaning redundant configuration files

2011-06-01 Thread Dale

Neil Bothwick wrote:

On Wed, 01 Jun 2011 13:06:23 -0500, Dale wrote:

   

I would think this would be a idea on this.  Do a emerge -C to get the
regular way and a emerge -CC to remove everything literally, including
config files.
 

So a bit of keyboard bounce can nuke your configs? No thanks. I'd rather
have an explicit option, like --purge.

   


True.  Of course, I always check my typing but others may not.  So, your 
idea is better than mine.


+1 for the new idea.

Dale

:-)  :-)



Re: [gentoo-user] Cleaning redundant configuration files

2011-05-31 Thread Dale

Graham Murray wrote:

Dalerdalek1...@gmail.com  writes:

   

There are times that if portage removed a config file, I would not be
happy.  Sometimes I unmerge a package then remerge but want to keep
the config files.

Would I like there to be the option, yep, I sure would.  There are
also times when I want to get rid of a package and all its config
files.  The option would be nice but it should be a option.
 

I think that the ideal would be if portage could set some kind of
'marker' so that etc-update, dispatch-conf etc could prompt the user as
to whether to keep or remove the orphaned file.

   


That would work and may even be better.  Either way, keeping unneeded 
config files out would be good.  We got tools to clean out everything 
else so may as well have that too.  Now getting someone to come up with 
one, that could be interesting for sure.


Since portage has so many options already, I wonder what letter it would 
get?  Are there even any good ones left.  Maybe it would be a number 
like oneshot.  o_O


Dale

:-)  :-)



Re: [gentoo-user] Cleaning redundant configuration files

2011-05-31 Thread Alan McKinnon
On Tue, May 31, 2011 at 12:08 AM, David W Noon dwn...@ntlworld.com wrote:
 On Mon, 30 May 2011 21:20:01 +0200, Neil Bothwick wrote about Re:
 [gentoo-user] Cleaning redundant configuration files:

On Mon, 30 May 2011 19:05:10 +0100, David W Noon wrote:
 [snip]
 The only algorithmic approach with which I would feel comfortable
 would be if the file were checked against the previous contents of a
 package and found present, but has disappeared from the new contents
 of that same package.  Even then, I would want manual confirmation.

That omits the most common cause of orphaned files, that the package
owning it has been unmerged.

 You have just touched on an annoyance of unmerge, in that it does not
 clean up configuration files that have been modified.  It removes files
 that are still in the same state as when the package was emerged, but
 not those modified by the user.  I don't see how user changes make the
 file more important than would be in its vanilla state.

 Perhaps an option to remove (by an unmerge, not etc-update or the
 like) these genuinely orphaned files could be set in /etc/make.conf.

The logic appears to be that an unmodified file will be re-instated
as-is should the package be re-merged, so nothing changes. A modified
config file is more problematic - if the package is re-merged, which
version should be used? The old one or the new vanilla one? Presumably
the user modified the file last time round for a reason and that
reason might still be valid.

Only one sensible choice remains - present both files to the human
user and ask them to decide.

If memory serves, this is in some doc somewhere, I know I read it long
ago but don't remember where.


-- 
Alan McKinnon
alan dot mckinnon at gmail dot com



Re: [gentoo-user] Cleaning redundant configuration files

2011-05-31 Thread Volker Armin Hemmann
Cfg-update has such a logic. It looks for user changes, If there are
decisions to make at all and previous decisions.

Ihatethespellcheckerofmyphone.

Am 31.05.2011 08:49 schrieb Alan McKinnon alan.mckin...@gmail.com:

On Tue, May 31, 2011 at 12:08 AM, David W Noon dwn...@ntlworld.com wrote:
 On Mon, 30 May 2011 21...
The logic appears to be that an unmodified file will be re-instated
as-is should the package be re-merged, so nothing changes. A modified
config file is more problematic - if the package is re-merged, which
version should be used? The old one or the new vanilla one? Presumably
the user modified the file last time round for a reason and that
reason might still be valid.

Only one sensible choice remains - present both files to the human
user and ask them to decide.

If memory serves, this is in some doc somewhere, I know I read it long
ago but don't remember where.


--
Alan McKinnon
alan dot mckinnon at gmail dot com


Re: [gentoo-user] Cleaning redundant configuration files

2011-05-31 Thread Neil Bothwick
On Mon, 30 May 2011 23:08:08 +0100, David W Noon wrote:

 You have just touched on an annoyance of unmerge, in that it does not
 clean up configuration files that have been modified.  It removes files
 that are still in the same state as when the package was emerged, but
 not those modified by the user.  I don't see how user changes make the
 file more important than would be in its vanilla state.

It doesn't remove *any* files that have been modified, the reasons
systems used to get cluttered with orphaned .la files. The logic is quite
simple, if it is not the file portage installed with the package, it
should not be uninstalled with the package. There are times when some
sort of --force-remove option to remove both these and files in
CONFIG_PROTECTed directories would be useful.


-- 
Neil Bothwick

Format: (v.) to erase irrevocably and unintentionally.
(n.) The process of such erasure.


signature.asc
Description: PGP signature


Re: [gentoo-user] Cleaning redundant configuration files

2011-05-31 Thread James Wall
On May 31, 2011 3:02 AM, Neil Bothwick n...@digimed.co.uk wrote:

 On Mon, 30 May 2011 23:08:08 +0100, David W Noon wrote:

  You have just touched on an annoyance of unmerge, in that it does not
  clean up configuration files that have been modified.  It removes files
  that are still in the same state as when the package was emerged, but
  not those modified by the user.  I don't see how user changes make the
  file more important than would be in its vanilla state.

 It doesn't remove *any* files that have been modified, the reasons
 systems used to get cluttered with orphaned .la files. The logic is quite
 simple, if it is not the file portage installed with the package, it
 should not be uninstalled with the package. There are times when some
 sort of --force-remove option to remove both these and files in
 CONFIG_PROTECTed directories would be useful.

If you want to ensure that portage removes a configuration file then add
CONFIG_PROTECT_MASK=/etc to the unmerge line and portage will remove the
configuration files as well.

James Wall

 --
 Neil Bothwick

 Format: (v.) to erase irrevocably and unintentionally.
(n.) The process of such erasure.


Re: [gentoo-user] Cleaning redundant configuration files

2011-05-31 Thread Neil Bothwick
On Tue, 31 May 2011 07:34:22 -0500, James Wall wrote:

  It doesn't remove *any* files that have been modified, the reasons
  systems used to get cluttered with orphaned .la files. The logic is
  quite simple, if it is not the file portage installed with the
  package, it should not be uninstalled with the package. There are
  times when some sort of --force-remove option to remove both these
  and files in CONFIG_PROTECTed directories would be useful.
   
 If you want to ensure that portage removes a configuration file then add
 CONFIG_PROTECT_MASK=/etc to the unmerge line and portage will remove
 the configuration files as well.

That will only remove unmodified files, and to do that fully you need
CONFIG_PROTECT=-*. Portage doesn't remove any files that have been
modified since installation, whether they are in CONFIG_PROTECTEed paths
or not.


-- 
Neil Bothwick

Did you know that eskimos have 17 different words for linguist ?


signature.asc
Description: PGP signature


Re: [gentoo-user] Cleaning redundant configuration files

2011-05-31 Thread David W Noon
On Tue, 31 May 2011 10:10:01 +0200, Neil Bothwick wrote about Re:
[gentoo-user] Cleaning redundant configuration files:

On Mon, 30 May 2011 23:08:08 +0100, David W Noon wrote:

 You have just touched on an annoyance of unmerge, in that it does not
 clean up configuration files that have been modified.  It removes
 files that are still in the same state as when the package was
 emerged, but not those modified by the user.  I don't see how user
 changes make the file more important than would be in its vanilla
 state.

It doesn't remove *any* files that have been modified,

Erm ... that's what I wrote, above.  [That is, of course, predicated on
the assumption that installing Package A will not modify configuration
files owned by Package B, and vice-versa: all post-installation
modifications are performed by the user.]

the reasons
systems used to get cluttered with orphaned .la files. The logic is
quite simple, if it is not the file portage installed with the
package, it should not be uninstalled with the package.

Why should that be so?  If the user has modified a configuration file
after the previous installation and then unmerges the package, a repeat
of the configuration changes is all that is required to reinstate it if
the package is removed in its entirety.  The user might even be daring
and take a backup of the file(s) in question.

To repeat myself: I do not see a customized configuration file as being
any more important than a vanilla one.  If I understand a configuration
file well enough to customize it once, I remain capable of customizing
it again after a reinstall.

I should be clear here: a reinstall means from new, with no previous
version currently installed and is quite distinct from an upgrade or
rebuild.

There are
times when some sort of --force-remove option to remove both these and
files in CONFIG_PROTECTed directories would be useful.

Again, what I wrote.

I think we largely agree on this issue.
-- 
Regards,

Dave  [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
dwn...@ntlworld.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*


signature.asc
Description: PGP signature


Re: [gentoo-user] Cleaning redundant configuration files

2011-05-31 Thread Mick
On Tuesday 31 May 2011 17:26:43 David W Noon wrote:
 On Tue, 31 May 2011 10:10:01 +0200, Neil Bothwick wrote about Re:
 
 [gentoo-user] Cleaning redundant configuration files:
 On Mon, 30 May 2011 23:08:08 +0100, David W Noon wrote:
  You have just touched on an annoyance of unmerge, in that it does not
  clean up configuration files that have been modified.  It removes
  files that are still in the same state as when the package was
  emerged, but not those modified by the user.  I don't see how user
  changes make the file more important than would be in its vanilla
  state.
 
 It doesn't remove *any* files that have been modified,
 
 Erm ... that's what I wrote, above.  [That is, of course, predicated on
 the assumption that installing Package A will not modify configuration
 files owned by Package B, and vice-versa: all post-installation
 modifications are performed by the user.]
 
 the reasons
 systems used to get cluttered with orphaned .la files. The logic is
 quite simple, if it is not the file portage installed with the
 package, it should not be uninstalled with the package.
 
 Why should that be so?  If the user has modified a configuration file
 after the previous installation and then unmerges the package, a repeat
 of the configuration changes is all that is required to reinstate it if
 the package is removed in its entirety.  The user might even be daring
 and take a backup of the file(s) in question.

It seems that we have a different appreciation of the user's value of time in 
editing config files ...


 To repeat myself: I do not see a customized configuration file as being
 any more important than a vanilla one.  If I understand a configuration
 file well enough to customize it once, I remain capable of customizing
 it again after a reinstall.

I would *not* want to have to reconfigure sendmail, apache, mrtg, or umpteen 
other files from scratch if you don't mind.  I probably can't remember what I 
was doing 3 years ago (or whenever I might have edited them) and the whole 
ecosystem of keeping things going may be quite fragile to cope with portage 
doing away with files I had modified, *without* asking me!

Yes, I know there are back ups and rsync can be ran so as to not delete old 
config file back ups, but I find the current set up most convenient and  
sensible.  After all we're talking about a few extra KB for a small number of 
config files, hardly a space saver these days.

However, if we're talking of an additional option for those who want to use it 
to remove orphan config files, but which offers enough warnings to wake up the 
user, then I wouldn't of course object to that as long as it was not made the 
default setting.  Personally, unless there is mass demand for such a feature, 
I think that qfile -o is good enough for this purpose.

Anyway, just my 2c's.
-- 
Regards,
Mick


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-user] Cleaning redundant configuration files

2011-05-31 Thread David W Noon
On Tue, 31 May 2011 22:40:01 +0200, Mick wrote about Re: [gentoo-user]
Cleaning redundant configuration files:

On Tuesday 31 May 2011 17:26:43 David W Noon wrote:
[snip]
 To repeat myself: I do not see a customized configuration file as
 being any more important than a vanilla one.  If I understand a
 configuration file well enough to customize it once, I remain
 capable of customizing it again after a reinstall.

I would *not* want to have to reconfigure sendmail, apache, mrtg, or
umpteen other files from scratch if you don't mind.

In that case, do not unmerge them.  Just upgrade as needed.

Remember that I am writing purely about *unmerged* packages.  In the
case of a rebuild or upgrade, customizations would be preserved just
as they are now.
-- 
Regards,

Dave  [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
dwn...@ntlworld.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*


signature.asc
Description: PGP signature


Re: [gentoo-user] Cleaning redundant configuration files

2011-05-31 Thread Dale

David W Noon wrote:

On Tue, 31 May 2011 22:40:01 +0200, Mick wrote about Re: [gentoo-user]
Cleaning redundant configuration files:

   

On Tuesday 31 May 2011 17:26:43 David W Noon wrote:
 

[snip]
   

To repeat myself: I do not see a customized configuration file as
being any more important than a vanilla one.  If I understand a
configuration file well enough to customize it once, I remain
capable of customizing it again after a reinstall.
   

I would *not* want to have to reconfigure sendmail, apache, mrtg, or
umpteen other files from scratch if you don't mind.
 

In that case, do not unmerge them.  Just upgrade as needed.

Remember that I am writing purely about *unmerged* packages.  In the
case of a rebuild or upgrade, customizations would be preserved just
as they are now.
   


I have in the past unmerged a package, checked to make sure it is all 
gone and then emerged it again.  I think this type of situation is what 
people are talking about.  Since I have done this myself, I wouldn't 
want the config files to be deleted and others seem to be talking about 
the same thing.  That's my take on it at least.


It should be a option but not something that is done by default.

Dale

:-)  :-)



Re: [gentoo-user] Cleaning redundant configuration files

2011-05-31 Thread Neil Bothwick
On Tue, 31 May 2011 23:43:59 +0100, David W Noon wrote:

 Remember that I am writing purely about *unmerged* packages.  In the
 case of a rebuild or upgrade, customizations would be preserved just
 as they are now.

Sometimes it is necessary to unmerge a package before emerging a newer
version, either manually or by portage, to resolve blockers. Making
unmerge remove all config files would cause breakage in such a case.

There's a reason why the CONFIG_PROTECT variable is so named.


-- 
Neil Bothwick

Dream as if you'll live forever. Live as if you'll die today.


signature.asc
Description: PGP signature


Re: [gentoo-user] Cleaning redundant configuration files

2011-05-31 Thread Neil Bothwick
On Tue, 31 May 2011 17:26:43 +0100, David W Noon wrote:

  You have just touched on an annoyance of unmerge, in that it does not
  clean up configuration files that have been modified.  It removes
  files that are still in the same state as when the package was
  emerged, but not those modified by the user.  I don't see how user
  changes make the file more important than would be in its vanilla
  state.
 
 It doesn't remove *any* files that have been modified,
 
 Erm ... that's what I wrote, above. 

No it's not. You were referring to a special case of the general
statement I made.

 [That is, of course, predicated on
 the assumption that installing Package A will not modify configuration
 files owned by Package B, and vice-versa: all post-installation
 modifications are performed by the user.]

That is valid, provide collision-protect is included in FEATURES.


 the reasons
 systems used to get cluttered with orphaned .la files. The logic is
 quite simple, if it is not the file portage installed with the
 package, it should not be uninstalled with the package.
 
 Why should that be so?

It's quite simple logic, whether or not you agree with it. If a file is
modified, it is no longer the file portage installed, so portage does not
uninstall it. If anything, the problem is that the logic used by portage
is too simple.

 To repeat myself: I do not see a customized configuration file as being
 any more important than a vanilla one.

A customised file contains an investment of the user's time, a generic
file does not. That investment may be small or great, but it is not
for portage to determine that value and remove the file without the
user's consent.

 I should be clear here: a reinstall means from new, with no previous
 version currently installed and is quite distinct from an upgrade or
 rebuild.

Not as distinct as you may think. Portage updates a package by first
installing the new version then unmerging the old one. As it uses
checksums and timestamps to determine ownership of a file, this is safe
as it will not remove files from the new version that overwrote
identically-named files from the old package.

 There are
 times when some sort of --force-remove option to remove both these and
 files in CONFIG_PROTECTed directories would be useful.
 
 Again, what I wrote.
 
 I think we largely agree on this issue.

We agree on the usefulness of a purge-like option but not on the
desirability or otherwise of the current default behaviour


-- 
Neil Bothwick

A friend in need may turn out to be a nuisance.


signature.asc
Description: PGP signature


Re: [gentoo-user] Cleaning redundant configuration files

2011-05-31 Thread Peter Humphrey
On Wednesday 01 June 2011 00:14:04 Neil Bothwick wrote:

 It's quite simple logic... If a file is modified, it is no longer the file
 portage installed, so portage does not uninstall it. If anything, the
 problem is that the logic used by portage is too simple.

I don't think it's too simple. It seems exactly right for the task to me: 
clear, predictable and easily understood.

 A customised file contains an investment of the user's time, a generic
 file does not. That investment may be small or great, but it is not
 for portage to determine that value and remove the file without the
 user's consent.

Personally, I'd be livid if portage were to remove my carefully crafted work 
from time immemorial, without so much as a by-your-leave. Anyone who wants 
to delete his own work is free to do so, but the rest of us ought not to be 
required to suffer it.

-- 
Rgds
Peter



Re: [gentoo-user] Cleaning redundant configuration files

2011-05-31 Thread Dale

Neil Bothwick wrote:

On Tue, 31 May 2011 23:43:59 +0100, David W Noon wrote:

   

Remember that I am writing purely about *unmerged* packages.  In the
case of a rebuild or upgrade, customizations would be preserved just
as they are now.
 

Sometimes it is necessary to unmerge a package before emerging a newer
version, either manually or by portage, to resolve blockers. Making
unmerge remove all config files would cause breakage in such a case.

There's a reason why the CONFIG_PROTECT variable is so named.


   


I had thought of something like that being done manually but didn't 
think of portage doing it itself.  That's a better reason than mine even 
tho it does the same thing.


Dale

:-)  :-)



Re: [gentoo-user] Cleaning redundant configuration files

2011-05-30 Thread Neil Bothwick
On Mon, 30 May 2011 15:48:15 +0100, David W Noon wrote:

 How does the tool of choice determine if a file is redundant or not?
 
 Just because a configuration file is not associated with a Portage
 package [any more] does not necessarily mean it is redundant.

No, but it indicates the file warrants a closer look as it may be
orphaned. qfile is my tool of choice for this, it only list files and
deletes nothing.


-- 
Neil Bothwick

c:Press Enter to Exit


signature.asc
Description: PGP signature


Re: [gentoo-user] Cleaning redundant configuration files

2011-05-30 Thread David W Noon
On Mon, 30 May 2011 18:10:02 +0200, Neil Bothwick wrote about Re:
[gentoo-user] Cleaning redundant configuration files:

On Mon, 30 May 2011 15:48:15 +0100, David W Noon wrote:

 How does the tool of choice determine if a file is redundant or not?
 
 Just because a configuration file is not associated with a Portage
 package [any more] does not necessarily mean it is redundant.

No, but it indicates the file warrants a closer look as it may be
orphaned. qfile is my tool of choice for this, it only list files and
deletes nothing.

Indeed, I would be very wary of any tool that automatically deleted a
configuration file without backing it up.

The only algorithmic approach with which I would feel comfortable would
be if the file were checked against the previous contents of a package
and found present, but has disappeared from the new contents of that
same package.  Even then, I would want manual confirmation.
-- 
Regards,

Dave  [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
dwn...@ntlworld.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*


signature.asc
Description: PGP signature


Re: [gentoo-user] Cleaning redundant configuration files

2011-05-30 Thread Neil Bothwick
On Mon, 30 May 2011 19:05:10 +0100, David W Noon wrote:

  Just because a configuration file is not associated with a Portage
  package [any more] does not necessarily mean it is redundant.  
 
 No, but it indicates the file warrants a closer look as it may be
 orphaned. qfile is my tool of choice for this, it only list files and
 deletes nothing.  
 
 Indeed, I would be very wary of any tool that automatically deleted a
 configuration file without backing it up.
 
 The only algorithmic approach with which I would feel comfortable would
 be if the file were checked against the previous contents of a package
 and found present, but has disappeared from the new contents of that
 same package.  Even then, I would want manual confirmation.

That omits the most common cause of orphaned files, that the package
owning it has been unmerged.


-- 
Neil Bothwick

A friend in need may turn out to be a nuisance.


signature.asc
Description: PGP signature


Re: [gentoo-user] Cleaning redundant configuration files

2011-05-30 Thread Florian Philipp
Am 30.05.2011 20:05, schrieb David W Noon:
 On Mon, 30 May 2011 18:10:02 +0200, Neil Bothwick wrote about Re:
 [gentoo-user] Cleaning redundant configuration files:
 
 On Mon, 30 May 2011 15:48:15 +0100, David W Noon wrote:

 How does the tool of choice determine if a file is redundant or not?

 Just because a configuration file is not associated with a Portage
 package [any more] does not necessarily mean it is redundant.

 No, but it indicates the file warrants a closer look as it may be
 orphaned. qfile is my tool of choice for this, it only list files and
 deletes nothing.
 
 Indeed, I would be very wary of any tool that automatically deleted a
 configuration file without backing it up.
 
 The only algorithmic approach with which I would feel comfortable would
 be if the file were checked against the previous contents of a package
 and found present, but has disappeared from the new contents of that
 same package.  Even then, I would want manual confirmation.

This might also be one of the few cases where atime might be of
interest. If the file has not been accessed in the last complete
power-on/power-off cycle, chances are no application depends on it.

Of course, even then there are lots of false positives, for example
everything in /etc/skel

Regards,
Florian Philipp



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-user] Cleaning redundant configuration files

2011-05-30 Thread David W Noon
On Mon, 30 May 2011 21:20:01 +0200, Neil Bothwick wrote about Re:
[gentoo-user] Cleaning redundant configuration files:

On Mon, 30 May 2011 19:05:10 +0100, David W Noon wrote:
[snip]
 The only algorithmic approach with which I would feel comfortable
 would be if the file were checked against the previous contents of a
 package and found present, but has disappeared from the new contents
 of that same package.  Even then, I would want manual confirmation.

That omits the most common cause of orphaned files, that the package
owning it has been unmerged.

You have just touched on an annoyance of unmerge, in that it does not
clean up configuration files that have been modified.  It removes files
that are still in the same state as when the package was emerged, but
not those modified by the user.  I don't see how user changes make the
file more important than would be in its vanilla state.

Perhaps an option to remove (by an unmerge, not etc-update or the
like) these genuinely orphaned files could be set in /etc/make.conf.
-- 
Regards,

Dave  [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
dwn...@ntlworld.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*


signature.asc
Description: PGP signature


Re: [gentoo-user] Cleaning redundant configuration files

2011-05-30 Thread Dale

David W Noon wrote:


You have just touched on an annoyance of unmerge, in that it does not
clean up configuration files that have been modified.  It removes files
that are still in the same state as when the package was emerged, but
not those modified by the user.  I don't see how user changes make the
file more important than would be in its vanilla state.

Perhaps an option to remove (by an unmerge, not etc-update or the
like) these genuinely orphaned files could be set in /etc/make.conf.
   


There are times that if portage removed a config file, I would not be 
happy.  Sometimes I unmerge a package then remerge but want to keep the 
config files.


Would I like there to be the option, yep, I sure would.  There are also 
times when I want to get rid of a package and all its config files.  The 
option would be nice but it should be a option.


Dale

:-)  :-)



Re: [gentoo-user] Cleaning redundant configuration files

2011-05-30 Thread Graham Murray
Dale rdalek1...@gmail.com writes:

 There are times that if portage removed a config file, I would not be
 happy.  Sometimes I unmerge a package then remerge but want to keep
 the config files.

 Would I like there to be the option, yep, I sure would.  There are
 also times when I want to get rid of a package and all its config
 files.  The option would be nice but it should be a option.

I think that the ideal would be if portage could set some kind of
'marker' so that etc-update, dispatch-conf etc could prompt the user as
to whether to keep or remove the orphaned file.