pkg 1.4 freeze please test test test!

[Anton Afanasyev]

On Wed, Oct 29, 2014 at 1:08 PM, Baptiste Daroussin <bapt at freebsd.org>
wrote:

> On Wed, Oct 29, 2014 at 01:05:49PM -0700, Anton Afanasyev wrote:
> > On Tue, Oct 28, 2014 at 4:19 PM, Baptiste Daroussin <bapt at freebsd.org>
> > wrote:
> >
> > > - new 3 way merge code ("stolen" from the fossil-scm) to allow
> automerging
> > >   configuration files
> > > - new @config keyword to mark a file as a config file (during
> > >   upgrade/reinstallation it will try to merge the configuration with
> the
> > > one the
> > >   user may have modified) an option AUTOMERGE is available to prevent
> > >   automerging if automerge fails a .pkgnew file will be created along
> with
> > > the
> > >   untouched user version of the configuration
> > >
> > Would it make sense to let the user specify the merge tool to use and
> > always use it, instead of having to support the merge code within pkg?
>
> That will defeat cross installation/upgrades (install arm package in an
> arm chroot)
>
> but yes allowing a users to define their own merge tool in general instead
> of
> the internal one could make sense.
>
> regards,
> Bapt
>

I (and this is just a personal opinion of one man, of course) find it
better to be explicitly told that "this default config file has changed and
you need to review it and merge with your local changed copy, even if you
didn't make any drastic changes to your version", as opposed to "by the
way, we merged a new version of this config file with your changes", as
that forces one to know what and why has changed. I've already lost a
config file for one of my ports (squid, the last 2.something version) due
to it getting overwritten with the default, so wouldn't want anything like
that to happen again (and yes, I know, I must have backups; but that's not
the point here).

If auto-merging is going to stay, an option to turn it off and always use a
merge tool or perform the merge manually would be appreciated.


Anton