[gentoo-user] Cleaning redundant configuration files

[gentoo-user] Cleaning redundant configuration files

[David W Noon]

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

On Mon, 30 May 2011 08:40:02 +0200, Graham Murray wrote about Re:
[gentoo-user] haldaemon group/user:

>Do any of the config tools, etc-update, dispatch-conf, cfg-update etc,
>ever prompt for removing a redundant file? In my experience they only
>'trigger' for changed content within existing configuration files?

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.
-- 
Regards,

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

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

Re: [gentoo-user] Cleaning redundant configuration files

[Neil Bothwick]

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

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

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

Re: [gentoo-user] Cleaning redundant configuration files

[David W Noon]

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

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]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
dwnoon@ntlworld.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

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

Re: [gentoo-user] Cleaning redundant configuration files

[Neil Bothwick]

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

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.

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

Re: [gentoo-user] Cleaning redundant configuration files

[Florian Philipp]

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

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [gentoo-user] Cleaning redundant configuration files

[David W Noon]

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

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]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
dwnoon@ntlworld.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

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

Re: [gentoo-user] Cleaning redundant configuration files

[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

[Graham Murray]

Dale <rdalek1967@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.

Re: [gentoo-user] Cleaning redundant configuration files

[Dale]

Graham Murray wrote:
> Dale<rdalek1967@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

[Alan McKinnon]

On Tue, May 31, 2011 at 12:08 AM, David W Noon <dwnoon@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

[Volker Armin Hemmann]

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

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.mckinnon@gmail.com>:

On Tue, May 31, 2011 at 12:08 AM, David W Noon <dwnoon@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

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

Re: [gentoo-user] Cleaning redundant configuration files

[Neil Bothwick]

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

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.

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

Re: [gentoo-user] Cleaning redundant configuration files

[James Wall]

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

On May 31, 2011 3:02 AM, "Neil Bothwick" <neil@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.

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

Re: [gentoo-user] Cleaning redundant configuration files

[Neil Bothwick]

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

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 ?

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

Re: [gentoo-user] Cleaning redundant configuration files

[David W Noon]

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

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]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
dwnoon@ntlworld.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

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

Re: [gentoo-user] Cleaning redundant configuration files

[Mick]

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

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

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

Re: [gentoo-user] Cleaning redundant configuration files

[David W Noon]

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

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]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
dwnoon@ntlworld.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

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

Re: [gentoo-user] Cleaning redundant configuration files

[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

[Neil Bothwick]

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

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.

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

Re: [gentoo-user] Cleaning redundant configuration files

[Neil Bothwick]

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

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.

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

Re: [gentoo-user] Cleaning redundant configuration files

[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

[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

[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

[Neil Bothwick]

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

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.

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

Re: [gentoo-user] Cleaning redundant configuration files

[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

[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

[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

[David W Noon]

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

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]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
dwnoon@ntlworld.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

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

Re: [gentoo-user] Cleaning redundant configuration files

[David W Noon]

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

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]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
dwnoon@ntlworld.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

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

Re: [gentoo-user] Cleaning redundant configuration files

[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

[David W Noon]

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

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]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
dwnoon@ntlworld.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

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

Re: [gentoo-user] Cleaning redundant configuration files

[Neil Bothwick]

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

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.

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

Re: [gentoo-user] Cleaning redundant configuration files

[David W Noon]

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

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]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
dwnoon@ntlworld.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

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

Re: [gentoo-user] Cleaning redundant configuration files

[Todd Goodman]

* David W Noon <dwnoon@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]
> *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
> dwnoon@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

[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

[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

[David W Noon]

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

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]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
dwnoon@ntlworld.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

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

Re: [gentoo-user] Cleaning redundant configuration files

[David W Noon]

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

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]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
dwnoon@ntlworld.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

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

Re: [gentoo-user] Cleaning redundant configuration files

[David W Noon]

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

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]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
dwnoon@ntlworld.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

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

Re: [gentoo-user] Cleaning redundant configuration files

[Todd Goodman]

* David W Noon <dwnoon@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]
> *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
> dwnoon@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

[Dale]

Todd Goodman wrote:
> * David W Noon<dwnoon@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]
>> *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
>> dwnoon@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

[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

[Neil Bothwick]

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

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?

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

Re: [gentoo-user] Cleaning redundant configuration files

[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

[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

[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

[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

[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

[Neil Bothwick]

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

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?

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

Re: [gentoo-user] Cleaning redundant configuration files

[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

[Doug Hunley]

On Thu, Jun 2, 2011 at 10:22, Neil Bothwick <neil@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

[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

[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

[David W Noon]

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

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]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
dwnoon@ntlworld.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

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

Re: [gentoo-user] Cleaning redundant configuration files

[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

[Neil Bothwick]

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

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

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

Re: [gentoo-user] Cleaning redundant configuration files

[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

[Mick]

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

On Thursday 02 Jun 2011 15:40:17 Doug Hunley wrote:
> On Thu, Jun 2, 2011 at 10:22, Neil Bothwick <neil@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

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

Re: [gentoo-user] Cleaning redundant configuration files

[David W Noon]

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

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]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
dwnoon@ntlworld.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

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

Re: [gentoo-user] Cleaning redundant configuration files

[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

[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

[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

[Neil Bothwick]

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

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.

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

Re: [gentoo-user] Cleaning redundant configuration files

[Adam Carter]

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

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

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

(Sorry Volker)

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

Re: [gentoo-user] Cleaning redundant configuration files

[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.
> 
> Ooooooh! 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

[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

[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

[David W Noon]

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

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]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
dwnoon@ntlworld.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

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

Re: [gentoo-user] Cleaning redundant configuration files

[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

[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

[Alan McKinnon]

Apparently, though unproven, at 01:48 on Friday 03 June 2011, Stroller did 
opine thusly:

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

I can't remember a specific time that happened, but if it did then so be it.

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

Yes, this is true for the most part. It's how I am and I'm aware of it.

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

That part is mostly tongue-in cheek, I had thought it was self-evident.

> 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'm not afraid of admitting fault in myself - I did so just two days ago with 
Dale. Not to pick out Dale for any special reason, it's just the most recent 
example.

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

Well, thank you for speaking your mind. Very few people do that.

Is the issue now dealt with so we can move on?

-- 
alan dot mckinnon at gmail dot com

Re: [gentoo-user] Cleaning redundant configuration files

[David W Noon]

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

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]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
dwnoon@ntlworld.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

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

Re: [gentoo-user] Cleaning redundant configuration files

[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

[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

[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

[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.