| 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
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.
> 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
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.
>> > 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.
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.
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
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
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
>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
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,
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
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.
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
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.
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"
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(-)