[oe] [PATCH 3/3] base-files-3.0.14 configuration files

[Martin Jansa]

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,

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.openembedded.org/pipermail/openembedded-devel/attachments/20110321/97f4a947/attachment-0002.sig>