pkgbase update and progress

[Matthew Seaman]

On 11/08/2017 00:05, Ben Woods wrote:
> On Thu, 10 Aug 2017 at 11:35 pm, Matthew Seaman <matthew at freebsd.org> wrote:
> 
>> On 10/08/2017 16:21, Glen Barber wrote:
>>>> * Since we have no mechanism of properly merging changes to /etc
>>>> we simply copy files as needed with pc-updatemanager, and it is
>>>> difficult to maintain what should be updated, merged, or removed.
>>>>
>>> This is another long-standing item in the list of things to fix, indeed.
>>
>> The idea floated at BSDCam was to have a package that would install a
>> pristine copy of the /etc files under /var/db/etcupdate and prompt the
>> user to then use that tool to update or install their configs.  That
>> should provide a nice compromise between having the files available from
>> pkgs and not enforcing a specific mechanism (tools, not policy) to
>> update /etc.
>>
> I haven't attended either of the conferences, and I'm sure this would have
> been discussed, but for those of us who weren't there:
> 
> Pkgng has 3-way merge capability (copied from fossil-scm in pkg 1.4.0). Why
> are we considering using it? Not having ever seen this functionality used,
> I would have thought the only things to do would be agree on where the
> pristine old copy would be stored (.sample files in /etc?) and perhaps
> improve pkgng if the user experience isn't satisfactory.

Yes, that is another alternative.  At the moment we're all theorising
about this it's going to work, but until we can get empirical and start
testing some actual code, we aren't going to be drawing any firm
conclusions.

I think etcupdate(8) has a longer history and people are more familiar
with it whereas the 3-way merge code in pkg(8) has been exercised
relatively rarely.  There's also considerations about how this would fit
into various different workflows -- everything from people that only
ever download the standard pre-compiled packages for a release, to
developers trying to cross-build highly customized embedded systems.
Having a 'merge' step that is separated from the 'install' step seems
advantageous in that it allows a point where people can substitute in
their own alternatives for managing /etc files.

	Cheers,

	Matthew


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 931 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-pkgbase/attachments/20170811/3d25d1a6/attachment.sig>