[gentoo-dev] etc-update & ._cfg* files: major issue with gentoo?

[gentoo-dev] etc-update & ._cfg* files: major issue with gentoo?

[Dhruba Bandopadhyay]

Hello,

I am having great difficulty dealing with one particular feature of gentoo
and would like to bring it to your attention.  I am writing in length
since I very much like gentoo and would like to do whatever I can to
further its progress.

When emerging packages configuration files beginning with ._cfg* are left
in /etc and other locations and on subsequent emerges portage warns that
one has X number of files remaining.  Now, on many occassions I have had
several of these files on my system and have postponed dealing with them
simply because they are a hassle.  Once in a while however, I use
etc-update to sort them with care.

There are many problems with the way this is done for a non-expert user
(which may include myself) and the ones below are only a few of them.

(1) It is not completely clear which files should be deleted and which
overwritten.
(2) Errors can result from making necessary changes using etc-update.
(3) There are no guidelines on the use of etc-update.   Although,
documentation does warn that etc-update can be dangerous and must be used
with care, how is the non-expert user to interpret this advice and how
much does it really tell him about the use of it?
(4) If files are not sorted they stay in their locations indefinitely,
increase in number and portage warns the user about them on its every use.
(5) Even if one does see differences in older versions and new ones how
does one tell if these differences should be preserved or discarded?
(6) If errors or difficulties result how does one rollback?
(7) Shoud sorting be as time consuming as it is currently especially with
the interactive merging of text?

I can speak from experience about suffering from problems.  For instance
today, despite sorting files as carefully as I could, gdm won't load
anymore and shows no error messages since gdm files were overwritten
(luckily I use xdm) and also fonts in gnome related applications are now
huge and different because font locations were changed.  Now, I did look
at the content of these files before I replaced the older versions but how
is one to know beforehand what is going to cause issues?

I am not referring to specific errors here but discussing the
functionality of this feature.  Does this really have to be as much of an
effort and annoyance as it is now and must one lose out on the benefits of
new files simply because they do not dare overwrite the older files?  I
would hate for something like this to be a drawback of an otherwise
automated and applaudable OS.

I hope I have been clear in expressing myself and I don't think for a
minute that I'm alone in this issue.  Hence, I would very much like to
hear comments and suggestions whatever they may be from users and
developers alike.

Best wishes.
-- 
Dhruba Bandopadhyay | dhruba@codewordt.co.uk | ICQ 31628525
Gentoo Linux 1.4rc1 | Vanilla Sources 2.4.20 | Enlightenment 16.5



--
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: etc-update & ._cfg* files: major issue with gentoo?

[Brian Jackson]

I didn't even know about etc-update until I saw you mention it in your 
email. So, being the good sysadmin I am, I wrote a script that has similar 
functionality. I have actually been getting it ready to release for the past 
week or 2. I put it up at http://www.mdrx.com/brian/ It finds all the rogue 
._cfg* files and diff's them against the real cfg file and displays the 
diff's. Let me know if you find any problems with it. Also let me know if 
you would like to see any other features. 

 --Brian Jackson 

Dhruba Bandopadhyay writes: 

> Hello, 
> 
> I am having great difficulty dealing with one particular feature of gentoo
> and would like to bring it to your attention.  I am writing in length
> since I very much like gentoo and would like to do whatever I can to
> further its progress. 
> 
> When emerging packages configuration files beginning with ._cfg* are left
> in /etc and other locations and on subsequent emerges portage warns that
> one has X number of files remaining.  Now, on many occassions I have had
> several of these files on my system and have postponed dealing with them
> simply because they are a hassle.  Once in a while however, I use
> etc-update to sort them with care. 
> 
> There are many problems with the way this is done for a non-expert user
> (which may include myself) and the ones below are only a few of them. 
> 
> (1) It is not completely clear which files should be deleted and which
> overwritten.
> (2) Errors can result from making necessary changes using etc-update.
> (3) There are no guidelines on the use of etc-update.   Although,
> documentation does warn that etc-update can be dangerous and must be used
> with care, how is the non-expert user to interpret this advice and how
> much does it really tell him about the use of it?
> (4) If files are not sorted they stay in their locations indefinitely,
> increase in number and portage warns the user about them on its every use.
> (5) Even if one does see differences in older versions and new ones how
> does one tell if these differences should be preserved or discarded?
> (6) If errors or difficulties result how does one rollback?
> (7) Shoud sorting be as time consuming as it is currently especially with
> the interactive merging of text? 
> 
> I can speak from experience about suffering from problems.  For instance
> today, despite sorting files as carefully as I could, gdm won't load
> anymore and shows no error messages since gdm files were overwritten
> (luckily I use xdm) and also fonts in gnome related applications are now
> huge and different because font locations were changed.  Now, I did look
> at the content of these files before I replaced the older versions but how
> is one to know beforehand what is going to cause issues? 
> 
> I am not referring to specific errors here but discussing the
> functionality of this feature.  Does this really have to be as much of an
> effort and annoyance as it is now and must one lose out on the benefits of
> new files simply because they do not dare overwrite the older files?  I
> would hate for something like this to be a drawback of an otherwise
> automated and applaudable OS. 
> 
> I hope I have been clear in expressing myself and I don't think for a
> minute that I'm alone in this issue.  Hence, I would very much like to
> hear comments and suggestions whatever they may be from users and
> developers alike. 
> 
> Best wishes.
> -- 
> Dhruba Bandopadhyay | dhruba@codewordt.co.uk | ICQ 31628525
> Gentoo Linux 1.4rc1 | Vanilla Sources 2.4.20 | Enlightenment 16.5 
> 
>  
> 
> --
> gentoo-dev@gentoo.org mailing list 
> 
 

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: etc-update & ._cfg* files: major issue with gentoo?

[Viktor Lakics]

Brian and Dhruba,

This is exactly what etc-update does...I use it with vim diff mode,
which shows you diff side by side and let you make the changes if
you want, and drops you back to the selection of action...

etc-update even has an ncurses interface (undocumented), just set 
mode="1" in /etc/etc-update.conf.

For vim mode uncomment the relevant section in the same file.

There is a script published in the forums 

(http://forums.gentoo.org/viewtopic.php?t=13390&sid=8a5a38efe9621ddcc819c58efd50abbf),

which can "auto-update" your config files -> this is GREAT because
it helps you with those files YOU have not tuoched before (these are
updated) as for the rest what you custumised, you will want to know
what portage does with them...

Hope this helps... -- Viktor 




On Sun, Jan 05, 2003 at 08:27:40PM -0600, Brian Jackson wrote:
> I didn't even know about etc-update until I saw you mention it in your 
> email. So, being the good sysadmin I am, I wrote a script that has similar 
> functionality. I have actually been getting it ready to release for the 
> past week or 2. I put it up at http://www.mdrx.com/brian/ It finds all the 
> rogue ._cfg* files and diff's them against the real cfg file and displays 
> the diff's. Let me know if you find any problems with it. Also let me know 
> if you would like to see any other features. 
> 
> --Brian Jackson 
> 
> Dhruba Bandopadhyay writes: 
> 
> >Hello, 
> >
> >I am having great difficulty dealing with one particular feature of gentoo
> >and would like to bring it to your attention.  I am writing in length
> >since I very much like gentoo and would like to do whatever I can to
> >further its progress. 
> >
> >When emerging packages configuration files beginning with ._cfg* are left
> >in /etc and other locations and on subsequent emerges portage warns that
> >one has X number of files remaining.  Now, on many occassions I have had
> >several of these files on my system and have postponed dealing with them
> >simply because they are a hassle.  Once in a while however, I use
> >etc-update to sort them with care. 
> >
> >There are many problems with the way this is done for a non-expert user
> >(which may include myself) and the ones below are only a few of them. 
> >
> >(1) It is not completely clear which files should be deleted and which
> >overwritten.
> >(2) Errors can result from making necessary changes using etc-update.
> >(3) There are no guidelines on the use of etc-update.   Although,
> >documentation does warn that etc-update can be dangerous and must be used
> >with care, how is the non-expert user to interpret this advice and how
> >much does it really tell him about the use of it?
> >(4) If files are not sorted they stay in their locations indefinitely,
> >increase in number and portage warns the user about them on its every use.
> >(5) Even if one does see differences in older versions and new ones how
> >does one tell if these differences should be preserved or discarded?
> >(6) If errors or difficulties result how does one rollback?
> >(7) Shoud sorting be as time consuming as it is currently especially with
> >the interactive merging of text? 
> >
> >I can speak from experience about suffering from problems.  For instance
> >today, despite sorting files as carefully as I could, gdm won't load
> >anymore and shows no error messages since gdm files were overwritten
> >(luckily I use xdm) and also fonts in gnome related applications are now
> >huge and different because font locations were changed.  Now, I did look
> >at the content of these files before I replaced the older versions but how
> >is one to know beforehand what is going to cause issues? 
> >
> >I am not referring to specific errors here but discussing the
> >functionality of this feature.  Does this really have to be as much of an
> >effort and annoyance as it is now and must one lose out on the benefits of
> >new files simply because they do not dare overwrite the older files?  I
> >would hate for something like this to be a drawback of an otherwise
> >automated and applaudable OS. 
> >
> >I hope I have been clear in expressing myself and I don't think for a
> >minute that I'm alone in this issue.  Hence, I would very much like to
> >hear comments and suggestions whatever they may be from users and
> >developers alike. 
> >
> >Best wishes.
> >-- 
> >Dhruba Bandopadhyay | dhruba@codewordt.co.uk | ICQ 31628525
> >Gentoo Linux 1.4rc1 | Vanilla Sources 2.4.20 | Enlightenment 16.5 
> >
> > 
> >
> >--
> >gentoo-dev@gentoo.org mailing list 
> >
> 
> 
> --
> gentoo-dev@gentoo.org mailing list
> 

-- 
_______________________________________
Viktor Lakics
email: viktor@lakics.net

--
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: etc-update & ._cfg* files: major issue with gentoo?

[Brian Jackson]

I like my menus better ;) Mine will save the diff to a file and clean up the 
cfg file if you want. I don like that ability to show the diff again though. 
I think I might add it. I guess it is good to have choices. I was even 
thinking about writing a PyQT version. 

Viktor Lakics writes: 

> Brian and Dhruba, 
> 
> This is exactly what etc-update does...I use it with vim diff mode,
> which shows you diff side by side and let you make the changes if
> you want, and drops you back to the selection of action...

Thats nice if you use vim. I don't. 

> 
> etc-update even has an ncurses interface (undocumented), just set 
> mode="1" in /etc/etc-update.conf.

I just tried it out and it seems like only the first screen is curses, with 
everything else being text based. 

> 
> For vim mode uncomment the relevant section in the same file. 
> 
> There is a script published in the forums  
> 
> (http://forums.gentoo.org/viewtopic.php?t=13390&sid=8a5a38efe9621ddcc819c58efd50abbf), 
> 
> which can "auto-update" your config files -> this is GREAT because
> it helps you with those files YOU have not tuoched before (these are
> updated) as for the rest what you custumised, you will want to know
> what portage does with them... 
> 
> Hope this helps... -- Viktor  
> 
>  
> 
> 
> On Sun, Jan 05, 2003 at 08:27:40PM -0600, Brian Jackson wrote:
>> I didn't even know about etc-update until I saw you mention it in your 
>> email. So, being the good sysadmin I am, I wrote a script that has similar 
>> functionality. I have actually been getting it ready to release for the 
>> past week or 2. I put it up at http://www.mdrx.com/brian/ It finds all the 
>> rogue ._cfg* files and diff's them against the real cfg file and displays 
>> the diff's. Let me know if you find any problems with it. Also let me know 
>> if you would like to see any other features.  
>> 
>> --Brian Jackson  
>> 
>> Dhruba Bandopadhyay writes:  
>> 
>> >Hello, 
>> >
>> >I am having great difficulty dealing with one particular feature of gentoo
>> >and would like to bring it to your attention.  I am writing in length
>> >since I very much like gentoo and would like to do whatever I can to
>> >further its progress. 
>> >
>> >When emerging packages configuration files beginning with ._cfg* are left
>> >in /etc and other locations and on subsequent emerges portage warns that
>> >one has X number of files remaining.  Now, on many occassions I have had
>> >several of these files on my system and have postponed dealing with them
>> >simply because they are a hassle.  Once in a while however, I use
>> >etc-update to sort them with care. 
>> >
>> >There are many problems with the way this is done for a non-expert user
>> >(which may include myself) and the ones below are only a few of them. 
>> >
>> >(1) It is not completely clear which files should be deleted and which
>> >overwritten.
>> >(2) Errors can result from making necessary changes using etc-update.
>> >(3) There are no guidelines on the use of etc-update.   Although,
>> >documentation does warn that etc-update can be dangerous and must be used
>> >with care, how is the non-expert user to interpret this advice and how
>> >much does it really tell him about the use of it?
>> >(4) If files are not sorted they stay in their locations indefinitely,
>> >increase in number and portage warns the user about them on its every use.
>> >(5) Even if one does see differences in older versions and new ones how
>> >does one tell if these differences should be preserved or discarded?
>> >(6) If errors or difficulties result how does one rollback?
>> >(7) Shoud sorting be as time consuming as it is currently especially with
>> >the interactive merging of text? 
>> >
>> >I can speak from experience about suffering from problems.  For instance
>> >today, despite sorting files as carefully as I could, gdm won't load
>> >anymore and shows no error messages since gdm files were overwritten
>> >(luckily I use xdm) and also fonts in gnome related applications are now
>> >huge and different because font locations were changed.  Now, I did look
>> >at the content of these files before I replaced the older versions but how
>> >is one to know beforehand what is going to cause issues? 
>> >
>> >I am not referring to specific errors here but discussing the
>> >functionality of this feature.  Does this really have to be as much of an
>> >effort and annoyance as it is now and must one lose out on the benefits of
>> >new files simply because they do not dare overwrite the older files?  I
>> >would hate for something like this to be a drawback of an otherwise
>> >automated and applaudable OS. 
>> >
>> >I hope I have been clear in expressing myself and I don't think for a
>> >minute that I'm alone in this issue.  Hence, I would very much like to
>> >hear comments and suggestions whatever they may be from users and
>> >developers alike. 
>> >
>> >Best wishes.
>> >-- 
>> >Dhruba Bandopadhyay | dhruba@codewordt.co.uk | ICQ 31628525
>> >Gentoo Linux 1.4rc1 | Vanilla Sources 2.4.20 | Enlightenment 16.5 
>> >
>> > 
>> >
>> >--
>> >gentoo-dev@gentoo.org mailing list 
>> > 
>> 
>> 
>> --
>> gentoo-dev@gentoo.org mailing list 
>> 
> 
> -- 
> _______________________________________
> Viktor Lakics
> email: viktor@lakics.net 
> 
> --
> gentoo-dev@gentoo.org mailing list 
> 
 

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: etc-update & ._cfg* files: major issue with gentoo?

[Jeremy Wohl]

On Mon, Jan 06, 2003 at 05:24:14AM +0000, Viktor Lakics wrote:
> Brian and Dhruba,
> 
> This is exactly what etc-update does...I use it with vim diff mode,
> which shows you diff side by side and let you make the changes if
> you want, and drops you back to the selection of action...

Everyone's doing it...

I've been updating my script, at Brandon Low's request, to offer a Pythonic
alternative to etc-update's features.  Merging is broken, but I expect to
finish it off in the next few days (i.e. don't use.)  Incorporates most of
the outstanding bugzilla ideas to automerge where it can -- see source.

  http://igmus.org/atoms/viewcvs.cgi/?cvsroot=dispatch-conf

As this thread portends, flexible merging is the piece de resistance.

-jeremy
_____________________________________________________________________
jeremy wohl ..: http://igmus.org

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: etc-update & ._cfg* files: major issue with gentoo?

[Joseph Carter]

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

On Sun, Jan 05, 2003 at 08:27:40PM -0600, Brian Jackson wrote:
> I didn't even know about etc-update until I saw you mention it in your 
> email. So, being the good sysadmin I am, I wrote a script that has similar 
> functionality. I have actually been getting it ready to release for the 
> past week or 2. I put it up at http://www.mdrx.com/brian/ It finds all the 
> rogue ._cfg* files and diff's them against the real cfg file and displays 
> the diff's. Let me know if you find any problems with it. Also let me know 
> if you would like to see any other features. 

I personally wish etc-update were more along the lines of giving me a
diff3-style merge loaded into $VISUAL for me to tweak as I see fit, and
call that good enough.

diff3 output is what a conflict looks like in CVS, ie

  <<<<< local
  stuff here
  =====
  new stuff here
  >>>>> Gentoo

This is much easier to work with than sdiff unless you are really
comfortable with side-by-side diffs.  I never was.

-- 
Joseph Carter <knghtbrd@efn.org>                Hey, that's MY freak show!
 
The deafening silence taught me not to ask a bunch of geeks for advice
from their girlfriends


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

[gentoo-dev] Re: etc-update & ._cfg* files: major issue with gentoo?

[Kai Großjohann]

"Dhruba Bandopadhyay" <dhruba@codewordt.co.uk> writes:

> When emerging packages configuration files beginning with ._cfg* are left
> in /etc and other locations and on subsequent emerges portage warns that
> one has X number of files remaining.  Now, on many occassions I have had
> several of these files on my system and have postponed dealing with them
> simply because they are a hassle.  Once in a while however, I use
> etc-update to sort them with care.
>
> There are many problems with the way this is done for a non-expert user
> (which may include myself) and the ones below are only a few of them.

I think part of the problem is the display of the differences.
Suppose you install a package for the first time which installs
version A of /etc/foo.  You change this file manually, giving version
B.  Sometime later you install a new version of that package which
comes with version C of the file.

Now if you ask etc-update for a diff, it shows you the differences
between versions B and C.  However, these differences partly stem
from the changes you made between A and B, and partly they depend on
the changes the upstream version had between A and C.

I think it would be more useful to show the differences between A and
C.  Then etc-update could ask whether these differences should be
integrated into the current version.  When the user says yes, then B
is patched with the A->C diff, giving a new version D.  (Or maybe C
should be patched with the A->B diff?  Probably it doesn't make a
difference.)  This process can introduce conflicts (if B and C changed
the same line).  Then users might have to resolve these conflicts.

Personally, I use cfengine to circumvent such problems: I never edit
config files manually, I just let cfengine do it for me.  Then, when
a new version of a config file is to be installed, I just tell the
system to install it, and then I run cfengine which incorporates my
changes into the new version.

This requires some thought when writing cfengine scripts.  You have
to anticipate in which way the syntax of the config file might change
and then design your editing operations so that they will still work
with the changed syntax.  Of course, when the config file syntax has
changed radically, then this automatic method will fail.  I guess
that if you design the editing scripts sensibly, then you will see
such failures easily.  (The program doesn't start because of syntax
errors, or the cfengine edit script complains it can't find anything
to edit.)

But even in the cfengine case, it would be useful to stash the
original versions of config files somewhere such that a diff between
A and C could be requested.

What do people think?
-- 
Ambibibentists unite!



--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: etc-update & ._cfg* files: major issue with gentoo?

[Toby Dickenson]

On Monday 06 January 2003 7:25 am, Kai Großjohann wrote:

> But even in the cfengine case, it would be useful to stash the
> original versions of config files somewhere such that a diff between
> A and C could be requested.
>
> What do people think?

My /etc is full of manually created *.original files, so I can diff my manual 
edits against a portage (or rpm) original. It would be really nice for 
portage to automatically maintain these in /etc/portage-original (or 
wherever)



--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: etc-update & ._cfg* files: major issue with gentoo?

[Thomas T. Veldhouse]

Does this entire thread need to be crossposted to both gentoo-user and
gentoo-dev?

Thank in advance for your understanding,

Tom Veldhouse

---


On Monday 06 January 2003 7:25 am, Kai Großjohann wrote:

My /etc is full of manually created *.original files, so I can diff my
manual
edits against a portage (or rpm) original. It would be really nice for
portage to automatically maintain these in /etc/portage-original (or
wherever)




--
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: etc-update & ._cfg* files: major issue with gentoo?

[Bengt Gorden]

Kai Großjohann wrote:
>
> But even in the cfengine case, it would be useful to stash the
> original versions of config files somewhere such that a diff between
> A and C could be requested.
> 
> What do people think?

I maintain a RCS-repository for all the changed files in /etc. It works 
well for me. I don't think (althogh I'm not familiar with the internals 
of etc-update) that it should be that big a problem to script rcs to 
just check in the new file. If it breaks its no problem reverting the 
file. And you have the benefit of being able to make diffs between A and 
C, as mentioned before.

/Bengan





--
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: etc-update & ._cfg* files: major issue with gentoo?

[Kai Großjohann]

Bengt Gorden <bengan@sunet.se> writes:

> Kai Großjohann wrote:
>>
>> But even in the cfengine case, it would be useful to stash the
>> original versions of config files somewhere such that a diff between
>> A and C could be requested.
>> What do people think?
>
> I maintain a RCS-repository for all the changed files in /etc. It
> works well for me.

Great.  I would really appreciate something with that effect to be
the default, though.
-- 
Ambibibentists unite!


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: etc-update & ._cfg* files: major issue with gentoo?

[Brian Hall]

On Fri, Jan 10, 2003 at 12:10:57PM +0100, Kai Großjohann wrote:
> Bengt Gorden <bengan@sunet.se> writes:
> 
> > Kai Großjohann wrote:
> >
> > I maintain a RCS-repository for all the changed files in /etc. It
> > works well for me.
> 
> Great.  I would really appreciate something with that effect to be
> the default, though.

Seconded!


-- 
http://www.pcisys.net/~brihall
Linux Consultant

If there's one thing I can't stand, it's intolerance.

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: etc-update & ._cfg* files: major issue with gentoo?

[Oliver Rutherfurd]

----- Original Message -----
> From: "Brian Hall" <brihall@pcisys.net>
> To: "Kai Großjohann" <kai.grossjohann@uni-duisburg.de>
> Cc: <gentoo-dev@gentoo.org>; <gentoo-user@gentoo.org>
> Sent: Friday, January 10, 2003 10:25 AM
> Subject: Re: [gentoo-dev] Re: etc-update & ._cfg* files: major issue with
gentoo?
>

> On Fri, Jan 10, 2003 at 12:10:57PM +0100, Kai Großjohann wrote:
> > Bengt Gorden <bengan@sunet.se> writes:
> >
> > > Kai Großjohann wrote:
> > >
> > > I maintain a RCS-repository for all the changed files in /etc. It
> > > works well for me.
> >
> > Great.  I would really appreciate something with that effect to be
> > the default, though.
>
> Seconded!

Hi,

I've written an equivalent to "etc-update" which creates backups of the
config files before replacing them. Don't know how this compares to keeping
an RCS repository, but I figured I'd mention it in case there was any
interest.

It can be found here:

http://www.rutherfurd.net/gentoo/cfghelper/

-Ollie
--
http://www.rutherfurd.net/


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: etc-update & ._cfg* files: major issue with gentoo?

[Joseph Carter]

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

On Mon, Jan 06, 2003 at 08:25:17AM +0100, Kai Gro?johann wrote:
> But even in the cfengine case, it would be useful to stash the
> original versions of config files somewhere such that a diff between
> A and C could be requested.
> 
> What do people think?

I think you just described exactly what's needed for the diff3 merge I
commented on.  =)

-- 
Joseph Carter <knghtbrd@efn.org>                      Crazy in the coconut
 
<doogie> cat /dev/random | perl ?
<shaleh> doogie: it is also a valid sendmail.cf
<doogie> :)
* shaleh wants to try it but is afraid


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

Re: [gentoo-dev] etc-update & ._cfg* files: major issue with gentoo?

[Sven Vermeulen]

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

On Mon, Jan 06, 2003 at 01:41:08AM -0000, Dhruba Bandopadhyay wrote:
> (1) It is not completely clear which files should be deleted and which
> overwritten.

Those that you didn't alter may probably be overwritten by the newer version,
the others would probably be better left alone, but it's still a good idea to
see the new file, for instance if there are new options in the package.

I'm glad that Portage doesn't touch my configfiles. I should be prompted (as
I am) if there are new configfiles available, and I should be asked if I want
to use them or not. So for me Portage is working fine.

> (3) There are no guidelines on the use of etc-update.   Although,
> documentation does warn that etc-update can be dangerous and must be used
> with care, how is the non-expert user to interpret this advice and how
> much does it really tell him about the use of it?

[... From the FAQ ...]

When updating a package using emerge or ebuild, how do I avoid clobbering my
config files? 

Portage now includes config file management support by default. Type emerge
--help config for more details. The (overly) simple answer is that if a
package installs foo somewhere under /etc, and another foo already exists
there, then the new foo will instead be renamed to ._cfgxxxx_foo in that
directory. A useful tool for examining and updating any protected config
files is etc-update, currently obtained by emerge app-admin/gentoolkit. 

[... From the Portage Manual ...]

*  etc-update : shell script using vim to assist with the merging of /etc
		files (can be dangerous if used incorrectly)

If I am not mistaken, these are the only documents that mention etc-update.
In the Portage Manual is said that it can be dangerous if used incorrectly.
This is true, for instace when etc-update wants to use a new /etc/fstab
(which has occured frequently) and the user blindly accepts, he will be
placed with an illegal /etc/fstab.

However, I do believe that the person in question should be held liable for
his own actions. If he doesn't read what etc-update sais, he shouldn't use
it.


Perhaps a nice feature would be that etc-update sais if the original file has
been altered by the user or not, thus helping the user in his decision wheter
or not to use the new configfile.

> (4) If files are not sorted they stay in their locations indefinitely,
> increase in number and portage warns the user about them on its every use.

Don't tell me you want to disable the warning? There are occasions that ppl
just can't easily use etc-update after an emerge -pu world. For instance
systems that monitor the state of the important files with AIDE: they need to
do a lot more than just accept or decline etc-update proposals.

Or you just don't have the time for your configfiles right now; you surely
don't want to forget that there are new configfiles available? 

> (5) Even if one does see differences in older versions and new ones how
> does one tell if these differences should be preserved or discarded?

Lines with a "-" in front are removed, those with "+" in front are added. So
what you see are the differences between the old and the new configfile.

> (6) If errors or difficulties result how does one rollback?

Not. This could be handy, but also makes the system bigger. Not all ppl want
a Portage-handled rollback (I don't), since they have their own way of doing
things (it's called backupsà :).

> I can speak from experience about suffering from problems.  For instance
> today, despite sorting files as carefully as I could, gdm won't load
> anymore and shows no error messages since gdm files were overwritten
> (luckily I use xdm) and also fonts in gnome related applications are now
> huge and different because font locations were changed.  Now, I did look
> at the content of these files before I replaced the older versions but how
> is one to know beforehand what is going to cause issues?

Welcome to the wonderfull world of learning.
 
Wkr,
	Sven Vermeulen
-- 
	Fighting for peace is like fucking for virginity.

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

[gentoo-dev] Re: etc-update & ._cfg* files: major issue with gentoo?

[Kai Großjohann]

Dylan Carlson <absinthe@pobox.com> writes:

> With regard to pointing out which changes have occurred between a release, 
> I believe it should be left up to the user to view the release notes 
> supplied by the software in /usr/share/doc and make the appropriate 
> actions.  Or hope for good comments in the config file...

Hm?  Release notes...  Yeah, that might produce some useful data.

But I still think it would be more convenient for the user if Gentoo
just produced the right diffs.
-- 
Ambibibentists unite!


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: etc-update & ._cfg* files: major issue with gentoo?

[William Kenworthy]

diffs from what?  what happens if the user has made changes outside of
the way gentoo has configured the system?  I found this was a major
disavantage of Mandrake, as it had to assume that the user didnt fiddle
with the files - if you configured it manually for whatever reason, the
whole mandrake configuration system ended up broken.

BillK

On Sat, 2003-01-11 at 06:38, Kai Großjohann wrote:
> Dylan Carlson <absinthe@pobox.com> writes:
> 
> > With regard to pointing out which changes have occurred between a release, 
> > I believe it should be left up to the user to view the release notes 
> > supplied by the software in /usr/share/doc and make the appropriate 
> > actions.  Or hope for good comments in the config file...
> 
> Hm?  Release notes...  Yeah, that might produce some useful data.
> 
> But I still think it would be more convenient for the user if Gentoo
> just produced the right diffs.
> -- 
> Ambibibentists unite!
> 
> 
> --
> gentoo-dev@gentoo.org mailing list
> 
> 



--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: etc-update & ._cfg* files: major issue with gentoo?

[Joseph Carter]

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

On Sat, Jan 11, 2003 at 07:05:36AM +0800, William Kenworthy wrote:
> diffs from what?  what happens if the user has made changes outside of
> the way gentoo has configured the system?  I found this was a major
> disavantage of Mandrake, as it had to assume that the user didnt fiddle
> with the files - if you configured it manually for whatever reason, the
> whole mandrake configuration system ended up broken.

man diff3  =)

diff3 generates a merge diff for three versions of a file - the original,
an updated file, and a second updated file (ie, made by a sysadmin), and a
second version of an updated file (ie, made by Gentoo..)

RCS and CVS depend heavily on this for conflict resolution.

-- 
Joseph Carter <knghtbrd@efn.org>                          Here we go again
 
<_Anarchy_> acf: maybe April 1 next year slashdot needs to run "Rob Malda
            accepts new job as head of Debian project" 8)


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

[gentoo-dev] Re: etc-update & ._cfg* files: major issue with gentoo?

[Kai Großjohann]

William Kenworthy <billk@iinet.net.au> writes:

> diffs from what?  what happens if the user has made changes outside of
> the way gentoo has configured the system?

Let me reiterate my old example:

    package version 1.1 installs /etc/foo (call it version A)
    user edits /etc/foo (results in, say, version B)
    new pkg version 1.2 has different /etc/foo (version C)

Currently, Gentoo offers diffs between B and C, but diffs between A
and C would be more useful.

Stupid implementation idea: on installation of a package, copy all
config files to a safe place, such as /usr/share/etc or
/var/state/etc.

Then version A is still available, problem solved.

(I agree with the other posters that diff3 is even /more/ useful, but
that's easy to add once the right version (A) is available.)
-- 
Ambibibentists unite!


--
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Diff alternatives for etc-update (WAS: etc-update & ._cfg* files: major issue with gentoo?)

[Dylan Carlson]

On Saturday 11 January 2003 05:14am, Kai Großjohann wrote:
>
> (I agree with the other posters that diff3 is even /more/ useful, but
> that's easy to add once the right version (A) is available.)

I posted this in -user, but will do so again here... I believe one of the 
easier things we can do is add support for other diff utils in 
/etc/make.conf/.  kompare, kdiff3, gtkdiff, whatever...

It's faster & easier to parse things (particularly large files) accurately 
with a GUI diff util.  kdiff3 also allows you to type into the merge file 
freeform (in case you want to make a few more manual changes not in either 
file being diffed).

/etc/make.conf examples:

DIFFCOMMAND=/usr/bin/kdiff3 ${FILE1} ${FILE2} ${FILE3} -o ${MERGEFILE}

DIFFCOMMAND=/usr/bin/gtkdiff ${FILE1} ${FILE2} ${FILE3} -o ${MERGEFILE}

DIFFCOMMAND=cp ${FILE1} ${MERGEFILE} && /usr/bin/kde/3.1/bin/kompare 
${MERGEFILE} ${FILE2}

// Kompare doesn't have an -o option... it merges changes back into the
// first file specified on the commandline.  or the changes can be saved as
// a .diff file.

Ebuilds?  Yes.

* gtkdiff is in app-misc/gtkdiff
* kdiff3 is in dev-util/kdiff3
* kompare is part of kde-base/kdesdk

Cheers,
Dylan Carlson [absinthe@pobox.com]

--
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Diff alternatives for etc-update

[Dylan Carlson]

On Saturday 11 January 2003 03:54pm, Kai Großjohann wrote:
> > I posted this in -user, but will do so again here... I believe one of
> > the easier things we can do is add support for other diff utils in
> > /etc/make.conf/.  kompare, kdiff3, gtkdiff, whatever...
>
> But it's more important to diff the right files (or versions).
> IMVHO, it's 90% which version and 10% how the diff looks.

Sure, it's important to save the user a step by diffing the most recent 
version of the config file...

...however I believe it's more important that users (some of whom are not 
regularly diffing files) can clearly see & understand what's changing.  If 
they merge incorrectly, they can screw up their system.

I say -- allow them access to tools which might make that process easier.

Making it configurable allows the user to decide the tool they want to use 
to merge, instead of us trying to make everyone happy with our sdiff 
wrapper...

sdiff's fine as a default, obviously... it works as-is, but I think 
everyone would enjoy etc-update a lot more if they had a choice of tools.  
I suspect one day we'll have a better homegrown Gentoo tool, but I don't 
see that happening in the next 6 months...

Cheers,
Dylan Carlson [absinthe@pobox.com]

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Diff alternatives for etc-update

[Paul de Vrieze]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 493 bytes --]

On Saturday 11 January 2003 22:29, Dylan Carlson wrote:
>
> sdiff's fine as a default, obviously... it works as-is, but I think
> everyone would enjoy etc-update a lot more if they had a choice of tools.
> I suspect one day we'll have a better homegrown Gentoo tool, but I don't
> see that happening in the next 6 months...
>

Well take a look at /etc/etc-update.conf and take a shot at it. 

Paul

-- 
Paul de Vrieze
Junior Researcher
Mail: pauldv@cs.kun.nl
Homepage: http://www.devrieze.net

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

Re: [gentoo-dev] Re: Diff alternatives for etc-update

[Dylan Carlson]

On Saturday 11 January 2003 04:44pm, Paul de Vrieze wrote:
> > sdiff's fine as a default, obviously... it works as-is, but I think
> > everyone would enjoy etc-update a lot more if they had a choice of
> > tools. I suspect one day we'll have a better homegrown Gentoo tool,
> > but I don't see that happening in the next 6 months...
>
> Well take a look at /etc/etc-update.conf and take a shot at it.
>

/me eats his shoe.

Sorry, didn't know that was there.  The etc-update(1) man page I have 
doesn't reference that file... sorry if I wasted anyone's time.

Karl or someone might want to update the manpage though (unless mine is 
outdated for some reason), to include a See Also to /etc/etc-update.conf.

Cheers,
Dylan Carlson [absinthe@pobox.com]

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Diff alternatives for etc-update (WAS: etc-update & ._cfg* files: major issue with gentoo?)

[Peter Ruskin]

On Saturday 11 Jan 2003 15:19, Dylan Carlson wrote:
> On Saturday 11 January 2003 05:14am, Kai Großjohann wrote:
> > (I agree with the other posters that diff3 is even /more/ useful, but
> > that's easy to add once the right version (A) is available.)
<snip>
> * kdiff3 is in dev-util/kdiff3

emerge -s kdiff3 returns nothing here.

Peter
-- 
Gentoo-1.4.2.8 Unstable. KDE: 3.1.0 (RC6) Qt: 3.1.0
AMD Athlon(tm) XP 1900+ 512MB.	Kernel: 2.4.20-win4lin-r1-pnr.	GCC 3.2.1
Linux user #275590 (http://counter.li.org/). up 1 day, 17 h, 20 min


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Diff alternatives for etc-update (WAS: etc-update & ._cfg* files: major issue with gentoo?)

[Dylan Carlson]

On Monday 13 January 2003 05:39pm, Peter Ruskin wrote:
> > * kdiff3 is in dev-util/kdiff3
>
> emerge -s kdiff3 returns nothing here.

Well it was there, I believe... maybe it got taken out.  

http://bugs.gentoo.org/show_bug.cgi?id=10825

Cheers,
Dylan Carlson [absinthe@pobox.com]

--
gentoo-dev@gentoo.org mailing list