[oe] Upgrading files identified as CONFFILES?

[Bryan Evenson]

Paul,

> -----Original Message-----
> From: paul.betafive at gmail.com [mailto:paul.betafive at gmail.com] On Behalf
> Of Paul Barker
> Sent: Friday, November 07, 2014 5:59 AM
> To: Bryan Evenson
> Cc: openembedded-devel at lists.openembedded.org
> Subject: Re: [oe] Upgrading files identified as CONFFILES?
> 
> On 6 November 2014 15:28, Bryan Evenson <bevenson at melinkcorp.com>
> wrote:
> > Paul,
> >
> >> -----Original Message-----
> >> From: openembedded-devel-bounces at lists.openembedded.org
> >> [mailto:openembedded-devel-bounces at lists.openembedded.org] On
> Behalf
> >> Of Paul Barker
> >> Sent: Thursday, November 06, 2014 9:36 AM
> >> To: OE Devel
> >> Subject: Re: [oe] Upgrading files identified as CONFFILES?
> >>
> >> On 6 November 2014 14:06, Bryan Evenson <bevenson at melinkcorp.com>
> >> wrote:
> >> > All,
> >> >
> >> > First, please let me know if I should be directing this to a
> >> > different OE/yocto
> >> mailing list; I have a hard time figuring out which list is appropriate at
> times.
> >> >
> >> > I am on poky/dylan and am using NTP on my target system.  I would
> >> > like to
> >> change the configuration for NTP and push out the changes to devices
> >> that are firmware upgradable.  I made the change and pushed out the
> >> upgrade, but I see that ntp.conf did not get changed on at least one
> >> of the systems (the first one I checked).  Now I see that ntp.conf is
> >> listed under CONFFILES in the main ntp recipe
> >> (http://www.yoctoproject.org/docs/1.7/mega-
> >> manual/mega-manual.html#var-CONFFILES), which explains why it was
> not
> >> upgraded.
> >> >
> >> > First, I want to confirm how the CONFFILES parameter works.  If a
> >> > file is
> >> listed under CONFFILES, is that file never modified during an upgrade
> >> or is it only upgraded if it has not been modified (matches the
> >> default file from the previous package version)?  I am using opkg for
> >> package management if that makes a difference.
> >> >
> >> > Second, how do I force the NTP configuration to be upgraded?  For
> >> > my
> >> system, the user has no interface to modify the NTP configuration.
> >> So even though it is a configuration file, in my case I want ntp.conf
> >> to always match the version provided by the upgraded package.
> >> >
> >> > Thanks,
> >> > Bryan
> >> >
> >>
> >> This largely depends on the package manager. I can tell you how opkg
> >> works... If a file is listed in CONFFILES it is backed up before an
> >> update is applied. By default, if a conffile has changed, the new
> >> changes go into a file named "%s-opkg" where %s is the original file name.
> If "--force-maintainer"
> >> is passed as an argument or the option "force_maintainer" is set, the
> >> new changes overwrite the version in the file system. In opkg v0.3.0
> >> there will be a new "--ignore-maintainer" argument and
> >> "ignore_maintainer" option to keep the conffile unmodified but not store
> the changes in "%s-opkg".
> >>
> >> Hope that helps,
> >>
> >
> > Thanks for the detailed explanation.  And just to explore my options, if I
> were to add the following in my ntp bbappend:
> >
> > CONFFILES_${PN} = ""
> >
> > would that remove ntp.conf from the CONFFILES list and force the
> configuration to be updated each time it changes?
> >
> > Thanks,
> > Bryan
> 
> It looks like the list of CONFFILES is taken from the version of the package
> being installed. So if a file is listed in CONFFILES for the old version but not
> the new version, it won't be treated as a conf file and should just be
> overwritten.
> 
> This isn't a behaviour I've looked at in detail so please let me know if it works.
> 

I tried it out.  Note that for this recipe ntp.conf is the only item in CONFFILES for ntp, so I changed the CONFFILES listing to:

CONFFILES_${PN} = ""

in my bbappend to get rid of it.  To be clear, if there were more items listed in CONFFILES, I would have copied the listing from the original recipe and only removed the files that I wanted to ensure were overwritten on each upgrade.

I tested it with one system which had an ntp.conf that did not match the configuration file in the ipk.  After the upgrade with this recipe change, ntp.conf on the system was updated to match the version in the ipk.  So this looks like one method that could be used to do targeted modification of configuration files without allowing all configuration files to be overwritten.  Although I am using opkg for package management; I assume the same would be true for the other package management systems but I have no way to confirm.

Thanks,
Bryan