Patchwork [3/3] base-files-3.0.14 configuration files

login
register
mail settings
Submitter Peter Gsellmann
Date March 17, 2011, 10:54 a.m.
Message ID <201103171154.23397.pgsellmann@portner-elektronik.at>
Download mbox | patch
Permalink /patch/1515/
State Superseded
Headers show

Comments

Peter Gsellmann - March 17, 2011, 10:54 a.m.
Mark some files in ${sysconfdir} as configuration files so they are not blindly overwritten when upgrading

Signed-off-by: Peter Gsellmann <pgsellmann@portner-elektronik.at>
---
 recipes/base-files/base-files_3.0.14.bb |    7 ++++---
 1 files changed, 4 insertions(+), 3 deletions(-)
Phil Blundell - March 17, 2011, 11:10 a.m.
On Thu, 2011-03-17 at 11:54 +0100, Peter Gsellmann wrote:
> Mark some files in ${sysconfdir} as configuration files so they are not blindly overwritten when upgrading

I wonder if it would make sense to mark everything in ${sysconfdir} and
${sysconfdir}/default (but probably not other subdirs) as a conffile
automatically.  I don't think there are many/any files in there that
wouldn't want conffile treatment. 

> -CONFFILES_${PN} = "${sysconfdir}/fstab ${sysconfdir}/hostname"
> +CONFFILES_${PN} = "${sysconfdir}/fstab ${sysconfdir}/hostname ${sysconfdir}/motd \
> +    ${sysconfdir}/profile ${sysconfdir}/nsswitch.conf ${sysconfdir}/host.conf"
>  CONFFILES_${PN}_micro = ""
>  CONFFILES_${PN}_nylon = "${sysconfdir}/resolv.conf ${sysconfdir}/fstab ${sysconfdir}/hostname"
>  CONFFILES_${PN}_slugos = "${sysconfdir}/resolv.conf ${sysconfdir}/fstab ${sysconfdir}/hostname"

Those DISTRO overrides look a bit weird too.  I wonder if the slugos and
nylon ones ought really to be "CONFFILES_${PN}_prepend_DISTRO" or
something.  The intent of the micro one is fairly clear although I can't
immediately think why this would be useful given that micro doesn't use
O_P_M.

p.
Wolfgang Hauser - March 17, 2011, 12:53 p.m.
> Mark some files in ${sysconfdir} as configuration files so they are
not blindly overwritten when upgrading

I would suggest a pre-/post processing in the packages, like debian
does.
If a config file exists or is changed, the current File will be rotated
or, if possible, left as it is and the new 
file is installed beside the changed one.

Having too much config files makes it difficult to do an individual
configuration by own packages.

Regards
Wolfgang
Peter Gsellmann - March 17, 2011, 3:54 p.m.
Am Donnerstag, 17. März 2011, 13:53:27 schrieb Hauser, Wolfgang (external):
> > Mark some files in ${sysconfdir} as configuration files so they are
> not blindly overwritten when upgrading
> 
> I would suggest a pre-/post processing in the packages, like debian
> does.
> If a config file exists or is changed, the current File will be rotated
> or, if possible, left as it is and the new 
> file is installed beside the changed one.

The opkg does not touch a present config file, but installs the new file with the name *-opkg
So if you do a find /etc -name \*-opkg you see the conflicts.

Any sensible conversion from old to new config file should be made by the package itself.
Wolfgang Hauser - March 18, 2011, 8:59 a.m.
>> > Mark some files in ${sysconfdir} as configuration files so they are
>> not blindly overwritten when upgrading
>> 
>> I would suggest a pre-/post processing in the packages, like debian
>> does.
>> If a config file exists or is changed, the current File will be
rotated
>> or, if possible, left as it is and the new 
>> file is installed beside the changed one.

>The opkg does not touch a present config file, but installs the new
file with the name *-opkg
>So if you do a find /etc -name \*-opkg you see the conflicts.

>Any sensible conversion from old to new config file should be made by
the package itself.

As I experienced, opkg exits with an error code if a config file already
exists, so if you want to create an image, the process will break at
that error.
It wasn't possible to create an image automatically then.
Phil Blundell - March 18, 2011, 10:56 a.m.
On Fri, 2011-03-18 at 09:59 +0100, Hauser, Wolfgang (external) wrote:
> As I experienced, opkg exits with an error code if a config file already
> exists, so if you want to create an image, the process will break at
> that error.
> It wasn't possible to create an image automatically then.

I don't think that situation should ever arise during image
construction.  If there are two packages which ship the same conffile
and don't Conflict: with each other then that seems like it must be a
packaging bug.

What were the circumstances that caused this to happen for you?

p.
Peter Gsellmann - March 18, 2011, 1:08 p.m.
Am Freitag, 18. März 2011, 09:59:17 schrieb Hauser, Wolfgang (external):
> >> > Mark some files in ${sysconfdir} as configuration files so they are
> >> not blindly overwritten when upgrading
> >> 
> >> I would suggest a pre-/post processing in the packages, like debian
> >> does.
> >> If a config file exists or is changed, the current File will be
> rotated
> >> or, if possible, left as it is and the new 
> >> file is installed beside the changed one.
> 
> >The opkg does not touch a present config file, but installs the new
> file with the name *-opkg
> >So if you do a find /etc -name \*-opkg you see the conflicts.
> 
> >Any sensible conversion from old to new config file should be made by
> the package itself.
> 
> As I experienced, opkg exits with an error code if a config file already
> exists, so if you want to create an image, the process will break at
> that error.
> It wasn't possible to create an image automatically then.
If you create a fresh new image, the config files should not exist.
opkg should not complain.

Problem arises if you do a 'opkg upgrade' from the running target;
With patch, opkg knows about Conffiles of base-files:
root@us-3:~# opkg info base-files
Package: base-files
Version: 3.0.14-r101.9
Provides:
Status: install user installed
Section: base
Architecture: pcontrol_g20
Maintainer: Angstrom Developers <angstrom-distro-devel@linuxtogo.org>
MD5Sum: d5553232d20233866c7f626b7f1d6d4f
Size: 4336
Filename: base-files_3.0.14-r101.9_pcontrol_g20.ipk
Conffiles:
 /etc/fstab 8a0d747a1565dfb39ae3b27b33ab5031
 /etc/hostname 0e97f4187e8f27c48206165806f9310a
 /etc/motd d41d8cd98f00b204e9800998ecf8427e
 /etc/profile 573d43f3c53d5bdabca7ec2317f5eb28
 /etc/nsswitch.conf 109e33e2c91d1853b5bc56078a96aa18
 /etc/host.conf a61b9f6548d337c1cc1e5a4de39f7b7f
Source: file://nsswitch.conf file://motd file://inputrc file://host.conf file://profile file://profile.d file://fstab file://filesystems file://issue.net file://issue file://usbd file://share/dot.bashrc file://share/dot.profile file://licenses/BSD file://licenses/GPL-2 file://licenses/GPL-3 file://licenses/LGPL-2 file://licenses/LGPL-2.1 file://licenses/LGPL-3 file://licenses/GFDL-1.2 file://licenses/Artistic
Description: Miscellaneous files for the base system.
Installed-Time: 1300270958


As you can see, opkg maintains some md5-hash value for the unchanged Conffile so a sensible conflict resolution is possible.
If it is not done so, its a opkg bug

Tested: it is possible to create an image with this patch.
Tested: 'opkg upgrade' handles the Conffiles as expected.

Peter
Martin Jansa - March 18, 2011, 3:30 p.m.
On Fri, Mar 18, 2011 at 02:08:15PM +0100, Peter Gsellmann wrote:
> Am Freitag, 18. März 2011, 09:59:17 schrieb Hauser, Wolfgang (external):
> > >> > Mark some files in ${sysconfdir} as configuration files so they are
> > >> not blindly overwritten when upgrading
> > >> 
> > >> I would suggest a pre-/post processing in the packages, like debian
> > >> does.
> > >> If a config file exists or is changed, the current File will be
> > rotated
> > >> or, if possible, left as it is and the new 
> > >> file is installed beside the changed one.
> > 
> > >The opkg does not touch a present config file, but installs the new
> > file with the name *-opkg
> > >So if you do a find /etc -name \*-opkg you see the conflicts.
> > 
> > >Any sensible conversion from old to new config file should be made by
> > the package itself.
> > 
> > As I experienced, opkg exits with an error code if a config file already
> > exists, so if you want to create an image, the process will break at
> > that error.
> > It wasn't possible to create an image automatically then.
> If you create a fresh new image, the config files should not exist.
> opkg should not complain.

Looks like you two are talking about 2 different things.

W) If 2 different packages are installing same config file, opkg won't
overwrite it and image creation would also fail

P) If same package is trying to install newer version of config file it
overwrites it silently when md5 sums are the same or file is not in
CONFFILES or creates config.file-opkg otherwise.

So the patch idea looks sane to me, only please check why there is
unused conffiles variable and maybe use it as default CONFFILES or
remove it completely.

Regards,
 
> Problem arises if you do a 'opkg upgrade' from the running target;
> With patch, opkg knows about Conffiles of base-files:
> root@us-3:~# opkg info base-files
> Package: base-files
> Version: 3.0.14-r101.9
> Provides:
> Status: install user installed
> Section: base
> Architecture: pcontrol_g20
> Maintainer: Angstrom Developers <angstrom-distro-devel@linuxtogo.org>
> MD5Sum: d5553232d20233866c7f626b7f1d6d4f
> Size: 4336
> Filename: base-files_3.0.14-r101.9_pcontrol_g20.ipk
> Conffiles:
>  /etc/fstab 8a0d747a1565dfb39ae3b27b33ab5031
>  /etc/hostname 0e97f4187e8f27c48206165806f9310a
>  /etc/motd d41d8cd98f00b204e9800998ecf8427e
>  /etc/profile 573d43f3c53d5bdabca7ec2317f5eb28
>  /etc/nsswitch.conf 109e33e2c91d1853b5bc56078a96aa18
>  /etc/host.conf a61b9f6548d337c1cc1e5a4de39f7b7f
> Source: file://nsswitch.conf file://motd file://inputrc file://host.conf file://profile file://profile.d file://fstab file://filesystems file://issue.net file://issue file://usbd file://share/dot.bashrc file://share/dot.profile file://licenses/BSD file://licenses/GPL-2 file://licenses/GPL-3 file://licenses/LGPL-2 file://licenses/LGPL-2.1 file://licenses/LGPL-3 file://licenses/GFDL-1.2 file://licenses/Artistic
> Description: Miscellaneous files for the base system.
> Installed-Time: 1300270958
> 
> 
> As you can see, opkg maintains some md5-hash value for the unchanged Conffile so a sensible conflict resolution is possible.
> If it is not done so, its a opkg bug
> 
> Tested: it is possible to create an image with this patch.
> Tested: 'opkg upgrade' handles the Conffiles as expected.
> 
> Peter
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Peter Gsellmann - March 18, 2011, 5:37 p.m.
Hi Martin!

Am Freitag, 18. März 2011, 16:30:48 schrieb Martin Jansa:
> On Fri, Mar 18, 2011 at 02:08:15PM +0100, Peter Gsellmann wrote:
> > Am Freitag, 18. März 2011, 09:59:17 schrieb Hauser, Wolfgang (external):
> > > >> > Mark some files in ${sysconfdir} as configuration files so they are
> > > >> not blindly overwritten when upgrading
> > > >> 
> > > >> I would suggest a pre-/post processing in the packages, like debian
> > > >> does.
> > > >> If a config file exists or is changed, the current File will be
> > > rotated
> > > >> or, if possible, left as it is and the new 
> > > >> file is installed beside the changed one.
> > > 
> > > >The opkg does not touch a present config file, but installs the new
> > > file with the name *-opkg
> > > >So if you do a find /etc -name \*-opkg you see the conflicts.
> > > 
> > > >Any sensible conversion from old to new config file should be made by
> > > the package itself.
> > > 
> > > As I experienced, opkg exits with an error code if a config file already
> > > exists, so if you want to create an image, the process will break at
> > > that error.
> > > It wasn't possible to create an image automatically then.
> > If you create a fresh new image, the config files should not exist.
> > opkg should not complain.
> 
> Looks like you two are talking about 2 different things.
> 
> W) If 2 different packages are installing same config file, opkg won't
> overwrite it and image creation would also fail
This should considered as bug in opkg;
why 2 packages may not use the same Conffile?
For example one would split 'ntp' into 'ntpd' and 'ntpdate':
  both should use the servers in /etc/ntp.conf .
In present configuration you have to syncronize 2 files /etc/ntp.conf
  and /etc/ntp/step-tickers .

> P) If same package is trying to install newer version of config file it
> overwrites it silently when md5 sums are the same or file is not in
> CONFFILES or creates config.file-opkg otherwise.
This should considered as user error to 'install' a package instead of 'upgrade'.

> So the patch idea looks sane to me, only please check why there is
> unused conffiles variable and maybe use it as default CONFFILES or
> remove it completely.
I think you talk about CONFFILES_${PN}_micro, CONFFILES_${PN}_nylon, CONFFILES_${PN}_slugos ?
For 'nylon' and 'slugos' it generates an additional empty file /etc/resolv.conf .
Otherwise this file is not owned by any package even so it exists!
  (anybody knows who creates it?)
Could this be written as:
CONFFILES_${PN}_nylon = ${CONFFILES_${PN}} + "${sysconfdir}/resolv.conf"
  or is there a smarter syntax?

OTOH, declaring 'base-files' as owner of /etc/resolv.conf for _all_ images
  would be the better solution (in my opinion). Votings?


For 'micro' the list is empty! What is the advantage of an empty list for this image?
I dont know and for this i am a bit reluctant to remove it.



Peter
Wolfgang Hauser - March 21, 2011, 9:11 a.m.
>What were the circumstances that caused this to happen for you?
>
>p.

The "problem" we have is: we have to create a flushable totally
read-only image for our system.

Therefore we have to overlay, in my opinion, a huge number of recipes to
modify the basic packages for doing offline configurations only.

Most of the modifications are related to a view scripts and
configurations (paths,...) of several packages.

In past I haven't found a solutions to do this in a easy way, w/o
copying the whole recipe and modify it.

To use a copy of a recipe cuts us off from the ongoing development and
bug fixing. This results in a huge amount of maintenance.   

So for me it might be an better way to have the files needed for the
configuration of packages at locations beside their original location.
(It might be there have to be a consequent usage of update alternatives
in OE for all packages.)

I had a look on the amend class, but there is not enough documentation
to get it to fly. I haven't managed to resolve my needs using 
amend.

Regards
Wolfgang
Martin Jansa - March 21, 2011, 9:30 a.m.
On Fri, Mar 18, 2011 at 06:37:04PM +0100, Peter Gsellmann wrote:
> Hi Martin!

Hi,
 
> Am Freitag, 18. März 2011, 16:30:48 schrieb Martin Jansa:
> > On Fri, Mar 18, 2011 at 02:08:15PM +0100, Peter Gsellmann wrote:
> > > Am Freitag, 18. März 2011, 09:59:17 schrieb Hauser, Wolfgang (external):
> > > > >> > Mark some files in ${sysconfdir} as configuration files so they are
> > > > >> not blindly overwritten when upgrading
> > > > >> 
> > > > >> I would suggest a pre-/post processing in the packages, like debian
> > > > >> does.
> > > > >> If a config file exists or is changed, the current File will be
> > > > rotated
> > > > >> or, if possible, left as it is and the new 
> > > > >> file is installed beside the changed one.
> > > > 
> > > > >The opkg does not touch a present config file, but installs the new
> > > > file with the name *-opkg
> > > > >So if you do a find /etc -name \*-opkg you see the conflicts.
> > > > 
> > > > >Any sensible conversion from old to new config file should be made by
> > > > the package itself.
> > > > 
> > > > As I experienced, opkg exits with an error code if a config file already
> > > > exists, so if you want to create an image, the process will break at
> > > > that error.
> > > > It wasn't possible to create an image automatically then.
> > > If you create a fresh new image, the config files should not exist.
> > > opkg should not complain.
> > 
> > Looks like you two are talking about 2 different things.
> > 
> > W) If 2 different packages are installing same config file, opkg won't
> > overwrite it and image creation would also fail
> This should considered as bug in opkg;
> why 2 packages may not use the same Conffile?
> For example one would split 'ntp' into 'ntpd' and 'ntpdate':
>   both should use the servers in /etc/ntp.conf .
> In present configuration you have to syncronize 2 files /etc/ntp.conf
>   and /etc/ntp/step-tickers .

well maybe it makes sense for files from CONFFILES, but certainly you
don't want some other package to overwrite binary owned by other package
etc.. so I think that it's working the same for CONFFILES and such
"usefull" colisions are so seldom that nobody cared to create exception.

> > P) If same package is trying to install newer version of config file it
> > overwrites it silently when md5 sums are the same or file is not in
> > CONFFILES or creates config.file-opkg otherwise.
> This should considered as user error to 'install' a package instead of 'upgrade'.

it's the same with upgrade, by "install newer version" I actually meant
"opkg upgrade", sorry I wasn't clear.

> > So the patch idea looks sane to me, only please check why there is
> > unused conffiles variable and maybe use it as default CONFFILES or
> > remove it completely.
> I think you talk about CONFFILES_${PN}_micro, CONFFILES_${PN}_nylon, CONFFILES_${PN}_slugos ?

No, about conffiles (lowercase)
<snip>
volatiles = "cache run log lock tmp"
conffiles = "${sysconfdir}/debian_version ${sysconfdir}/host.conf \
             ${sysconfdir}/inputrc ${sysconfdir}/issue /${sysconfdir}/issue.net \
             ${sysconfdir}/nsswitch.conf ${sysconfdir}/profile \
             ${sysconfdir}/default"
</snip>

> For 'nylon' and 'slugos' it generates an additional empty file /etc/resolv.conf .
> Otherwise this file is not owned by any package even so it exists!
>   (anybody knows who creates it?)
> Could this be written as:
> CONFFILES_${PN}_nylon = ${CONFFILES_${PN}} + "${sysconfdir}/resolv.conf"
>   or is there a smarter syntax?
> 
> OTOH, declaring 'base-files' as owner of /etc/resolv.conf for _all_ images
>   would be the better solution (in my opinion). Votings?
> 
> 
> For 'micro' the list is empty! What is the advantage of an empty list for this image?
> I dont know and for this i am a bit reluctant to remove it.

IIRC someone in this thread said it's because micro is not using ONLINE_PACKAGE_MANAGEMENT..

Regards,
Peter Gsellmann - March 21, 2011, 11:36 a.m.
Hi Martin!

Am Montag, 21. März 2011, 10:30:21 schrieb Martin Jansa:
> On Fri, Mar 18, 2011 at 06:37:04PM +0100, Peter Gsellmann wrote:
> > Am Freitag, 18. März 2011, 16:30:48 schrieb Martin Jansa:
> > > On Fri, Mar 18, 2011 at 02:08:15PM +0100, Peter Gsellmann wrote:
> > > > Am Freitag, 18. März 2011, 09:59:17 schrieb Hauser, Wolfgang (external):
> > > > > >> > Mark some files in ${sysconfdir} as configuration files so they are
> > > > > >> not blindly overwritten when upgrading
> > > > > >> 
> > > > > >> I would suggest a pre-/post processing in the packages, like debian
> > > > > >> does.
> > > > > >> If a config file exists or is changed, the current File will be
> > > > > rotated
> > > > > >> or, if possible, left as it is and the new 
> > > > > >> file is installed beside the changed one.
> > > > > 
> > > > > >The opkg does not touch a present config file, but installs the new
> > > > > file with the name *-opkg
> > > > > >So if you do a find /etc -name \*-opkg you see the conflicts.
> > > > > 
> > > > > >Any sensible conversion from old to new config file should be made by
> > > > > the package itself.
> > > > > 
> > > > > As I experienced, opkg exits with an error code if a config file already
> > > > > exists, so if you want to create an image, the process will break at
> > > > > that error.
> > > > > It wasn't possible to create an image automatically then.
> > > > If you create a fresh new image, the config files should not exist.
> > > > opkg should not complain.
> > > 
> > > Looks like you two are talking about 2 different things.
> > > 
> > > W) If 2 different packages are installing same config file, opkg won't
> > > overwrite it and image creation would also fail
> > This should considered as bug in opkg;
> > why 2 packages may not use the same Conffile?
> > For example one would split 'ntp' into 'ntpd' and 'ntpdate':
> >   both should use the servers in /etc/ntp.conf .
> > In present configuration you have to syncronize 2 files /etc/ntp.conf
> >   and /etc/ntp/step-tickers .
> 
> well maybe it makes sense for files from CONFFILES, but certainly you
> don't want some other package to overwrite binary owned by other package
> etc.. so I think that it's working the same for CONFFILES and such
> "usefull" colisions are so seldom that nobody cared to create exception.
> 
> > > P) If same package is trying to install newer version of config file it
> > > overwrites it silently when md5 sums are the same or file is not in
> > > CONFFILES or creates config.file-opkg otherwise.
> > This should considered as user error to 'install' a package instead of 'upgrade'.
> 
> it's the same with upgrade, by "install newer version" I actually meant
> "opkg upgrade", sorry I wasn't clear.
> 
> > > So the patch idea looks sane to me, only please check why there is
> > > unused conffiles variable and maybe use it as default CONFFILES or
> > > remove it completely.
> > I think you talk about CONFFILES_${PN}_micro, CONFFILES_${PN}_nylon, CONFFILES_${PN}_slugos ?
> 
> No, about conffiles (lowercase)
> <snip>
> volatiles = "cache run log lock tmp"
> conffiles = "${sysconfdir}/debian_version ${sysconfdir}/host.conf \
>              ${sysconfdir}/inputrc ${sysconfdir}/issue /${sysconfdir}/issue.net \
>              ${sysconfdir}/nsswitch.conf ${sysconfdir}/profile \
>              ${sysconfdir}/default"
> </snip>
like this?
CONFFILES_${PN} = ${conffiles}
CONFFILES_${PN}_micro = ""
CONFFILES_${PN}_nylon = "${sysconfdir}/resolv.conf" + ${conffiles}
CONFFILES_${PN}_slugos = "${sysconfdir}/resolv.conf" + ${conffiles}

Patch follows (have to test before).

> > For 'micro' the list is empty! What is the advantage of an empty list for this image?
> > I dont know and for this i am a bit reluctant to remove it.
> 
> IIRC someone in this thread said it's because micro is not using ONLINE_PACKAGE_MANAGEMENT..
setting ONLINE_PACKAGE_MANAGEMENT = "none" precludes the use of CONFFILES_* in all recipes??
As i can see, ONLINE_PACKAGE_MANAGEMENT is misused for micro image.




Peter
Phil Blundell - March 21, 2011, 11:54 a.m.
On Mon, 2011-03-21 at 12:36 +0100, Peter Gsellmann wrote:
> setting ONLINE_PACKAGE_MANAGEMENT = "none" precludes the use of CONFFILES_* in all recipes??

It doesn't preclude it, but it does render CONFFILES fairly useless.

It looks like the CONFFILES_micro = "" in this particular recipe was
added by me in 2b4ab236.  I guess I probably did this to avoid having
nonexistent files show up in CONFFILES (since micro doesn't ship stuff
like motd at all).  I don't recall whether I did this just for neatness
or whether OE was actually issuing a diagnostic for that situation.

I guess it might make some sense to just set CONFFILES_micro = ""
globally in micro.conf rather than doing it in individual recipes.

> As i can see, ONLINE_PACKAGE_MANAGEMENT is misused for micro image.

What do you mean?

p.
Peter Gsellmann - March 21, 2011, 12:33 p.m.
Hi Phil!

Am Montag, 21. März 2011, 12:54:42 schrieb Phil Blundell:
> On Mon, 2011-03-21 at 12:36 +0100, Peter Gsellmann wrote:
> > setting ONLINE_PACKAGE_MANAGEMENT = "none" precludes the use of CONFFILES_* in all recipes??
> 
> It doesn't preclude it, but it does render CONFFILES fairly useless.
> 
> It looks like the CONFFILES_micro = "" in this particular recipe was
> added by me in 2b4ab236.  I guess I probably did this to avoid having
> nonexistent files show up in CONFFILES (since micro doesn't ship stuff
> like motd at all).  I don't recall whether I did this just for neatness
> or whether OE was actually issuing a diagnostic for that situation.
> 
> I guess it might make some sense to just set CONFFILES_micro = ""
> globally in micro.conf rather than doing it in individual recipes.
> 
> > As i can see, ONLINE_PACKAGE_MANAGEMENT is misused for micro image.
> 
> What do you mean?
Sorry, no misuse, but wrong cause assumed by me.
CONFFILES_${PN}_micro should not be empty but contain nsswitch.conf
  and hostname as these are the only you allow to exist.

Would this work for you?
CONFFILES_${PN}_micro = "${sysconfdir}/hostname ${sysconfdir}/nsswitch.conf"

Even if nothing on your target is honoring the configness of these files at least it is documented.



Peter
Phil Blundell - March 21, 2011, 1:58 p.m.
On Mon, 2011-03-21 at 13:33 +0100, Peter Gsellmann wrote:
> Would this work for you?
> CONFFILES_${PN}_micro = "${sysconfdir}/hostname ${sysconfdir}/nsswitch.conf"
> 
> Even if nothing on your target is honoring the configness of these files at least it is documented.

Yes, that sounds OK to me.

p.
Peter Gsellmann - March 21, 2011, 2:18 p.m.
Am Montag, 21. März 2011, 14:58:35 schrieb Phil Blundell:
> On Mon, 2011-03-21 at 13:33 +0100, Peter Gsellmann wrote:
> > Would this work for you?
> > CONFFILES_${PN}_micro = "${sysconfdir}/hostname ${sysconfdir}/nsswitch.conf"
> > 
> > Even if nothing on your target is honoring the configness of these files at least it is documented.
> 
> Yes, that sounds OK to me.
Is this acked-by? See [patch v2] in another branch of this thread.


Peter

Patch

diff --git a/recipes/base-files/base-files_3.0.14.bb b/recipes/base-files/base-files_3.0.14.bb
index acd12a4..6495d45 100644
--- a/recipes/base-files/base-files_3.0.14.bb
+++ b/recipes/base-files/base-files_3.0.14.bb
@@ -1,7 +1,7 @@ 
 DESCRIPTION = "Miscellaneous files for the base system."
 SECTION = "base"
 PRIORITY = "required"
-PR = "r100"
+PR = "r101"
 LICENSE = "GPL"
 
 SRC_URI = " \
@@ -95,7 +95,7 @@  do_install () {
 	fi
 
         if [ "${DISTRO}" != "micro" -a "${DISTRO}" != "micro-uclibc" ]; then
-                install -m 644 ${WORKDIR}/issue*  ${D}${sysconfdir}  
+                install -m 644 ${WORKDIR}/issue*  ${D}${sysconfdir}
 
                 if [ -n "${DISTRO_NAME}" ]; then
         		echo -n "${DISTRO_NAME} " >> ${D}${sysconfdir}/issue
@@ -181,7 +181,8 @@  PACKAGE_ARCH_rt3000 = "rt3000"
 
 PACKAGE_ARCH = "${MACHINE_ARCH}"
 
-CONFFILES_${PN} = "${sysconfdir}/fstab ${sysconfdir}/hostname"
+CONFFILES_${PN} = "${sysconfdir}/fstab ${sysconfdir}/hostname ${sysconfdir}/motd \
+    ${sysconfdir}/profile ${sysconfdir}/nsswitch.conf ${sysconfdir}/host.conf"
 CONFFILES_${PN}_micro = ""
 CONFFILES_${PN}_nylon = "${sysconfdir}/resolv.conf ${sysconfdir}/fstab ${sysconfdir}/hostname"
 CONFFILES_${PN}_slugos = "${sysconfdir}/resolv.conf ${sysconfdir}/fstab ${sysconfdir}/hostname"