From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6917993065941565440 X-Received: by 2002:adf:f6cc:: with SMTP id y12mr3375703wrp.35.1611305540504; Fri, 22 Jan 2021 00:52:20 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a05:600c:4ed1:: with SMTP id g17ls2578389wmq.1.gmail; Fri, 22 Jan 2021 00:52:19 -0800 (PST) X-Google-Smtp-Source: ABdhPJwPIYs6yfZ7DbNr7zMQx6sY32WO8dCsEVL094uTURjpPHLGDvC9mzOR+556or3XQodABcxz X-Received: by 2002:a1c:9a4d:: with SMTP id c74mr2836224wme.73.1611305539678; Fri, 22 Jan 2021 00:52:19 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1611305539; cv=none; d=google.com; s=arc-20160816; b=j+OuubTpqIl1urv1A0FbyfMWmZs8F2JUsFyfMEyFSRhOdHuHdwkZIWTgxqQPl0BR+X KAT0P0CQOFAWkEZ0YSqjA+lTY7Ngc5JkYUvTBaIeZNQR2naH0GngX1jYXyOpRlYJz7Pt 65QR4zLSAQBKHuoCTjcVQ+AajF+TpseDpGTbYX/vLFQkWJvALvn1iTETqOiifSJhyxaV VDLFFAgQCx8POhk4MY3k5aW2cuOIhVUBBe0WmjJqf1OdFk8xFrxtEdT8i0Y4hPrxUi/K kPeaEg76eEDM+/xWYZKbV9Sm44vEbEnFQq3YObmMagWvfxMQrFKlcM8l3+B0gPpmU+fY wJiw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:content-language:in-reply-to:mime-version :user-agent:date:message-id:organization:from:references:cc:to :subject; bh=ugwQ7h393bjUFAD6cF3PXz0R39ZZjz67PjL5iPFxCMw=; b=1AJhTZ3PELHjZyZIlMpFg7//s2MFj9dGDTKBljtLYAFt483zvB0ip7MEg+d7/3sjwH dLmyLxTUPkjzE1/GnfvbS0Q3OMirJeETXlauVKf+NBu2H/nkJWI7VGs9K+RrUIq/lN72 sqqJ+cqDUot6ZtbsuhC8JftNGfZgfrLqEQTKCiM/tFdxUkNS0ypOIhw7xJXG08+vAewD 8py/9KMLV7nBac+lHuKKfWFDbPrx/VUSKLUayZ6p0KUg5y0XK8q+2ZH43odTH1CINEJz XoUkPCgJuVZ9zhH1ju0HkGsG6gqSmemA34LLtf7QVqzwfSjCeyLVIyGGRBjKmgnxaxHp B0Lw== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=neutral (google.com: 212.18.0.9 is neither permitted nor denied by best guess record for domain of ch@denx.de) smtp.mailfrom=ch@denx.de Return-Path: Received: from mail-out.m-online.net (mail-out.m-online.net. [212.18.0.9]) by gmr-mx.google.com with ESMTPS id h10si257637wmq.4.2021.01.22.00.52.19 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 Jan 2021 00:52:19 -0800 (PST) Received-SPF: neutral (google.com: 212.18.0.9 is neither permitted nor denied by best guess record for domain of ch@denx.de) client-ip=212.18.0.9; Authentication-Results: gmr-mx.google.com; spf=neutral (google.com: 212.18.0.9 is neither permitted nor denied by best guess record for domain of ch@denx.de) smtp.mailfrom=ch@denx.de Received: from frontend01.mail.m-online.net (unknown [192.168.8.182]) by mail-out.m-online.net (Postfix) with ESMTP id 4DMY0z39C2z1qsZv; Fri, 22 Jan 2021 09:52:19 +0100 (CET) Received: from localhost (dynscan1.mnet-online.de [192.168.6.70]) by mail.m-online.net (Postfix) with ESMTP id 4DMY0z2sZlz1qqlF; Fri, 22 Jan 2021 09:52:19 +0100 (CET) X-Virus-Scanned: amavisd-new at mnet-online.de Received: from mail.mnet-online.de ([192.168.8.182]) by localhost (dynscan1.mail.m-online.net [192.168.6.70]) (amavisd-new, port 10024) with ESMTP id jwPOSJbBzH5N; Fri, 22 Jan 2021 09:52:18 +0100 (CET) X-Auth-Info: 5xy9IMux6JOeg6GCQEII0cAD4RkJALAXM38Zf+W6Uew= Received: from [10.88.0.186] (dslb-002-207-026-175.002.207.pools.vodafone-ip.de [2.207.26.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.mnet-online.de (Postfix) with ESMTPSA; Fri, 22 Jan 2021 09:52:18 +0100 (CET) Subject: Re: image-postproc-extension.bbclass modifying /etc/os-release To: Silvano Cirujano Cuesta , Henning Schild Cc: isar-users@googlegroups.com References: <67e1fac9-5af5-29aa-de57-9a0de0cdd165@siemens.com> <79cdea42-8338-2e7f-33dd-f396db634a14@siemens.com> <20210119092531.2cc80db5@md1za8fc.ad001.siemens.net> <20210119093324.52410271@md1za8fc.ad001.siemens.net> <34c9ad2c-a330-0074-cfd1-bffa1afcbd02@siemens.com> <20210119102246.53791a9c@md1za8fc.ad001.siemens.net> <12759268-1ad7-168a-dde9-4f2658567af1@siemens.com> From: Claudius Heine Organization: Denx Software Engineering Message-ID: <402794f7-74a3-ab50-972e-7682d5388ff2@denx.de> Date: Fri, 22 Jan 2021 09:52:18 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.1 MIME-Version: 1.0 In-Reply-To: <12759268-1ad7-168a-dde9-4f2658567af1@siemens.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-TUID: DghQn+wjUMff Hi Silvano, On 2021-01-19 11:37, Silvano Cirujano Cuesta wrote: > We can create a removal file diversion for /usr/lib/os-release (leaving /etc/os-release untouched, that way the Debian manpage for os-release still applies). This approach has following attributes: > > - /usr/lib/os-release is not managed by any package and that way post-processing it is not an issue and dpkg won't break anything > > - Debian os-release manpage still applies > > If going for the other approach (create our own "base-files" package) we can do pretty much the same: > > - the package doesn't provide /usr/lib/os-release, leaving it package-unmanaged > > - image post-processing to create the file becomes a requirement I looked at the manpage of os-release and it does not state that `/etc/os-release` can or should not be a file: ``` The file /etc/os-release takes precedence over /usr/lib/os-release. Applications should check for the former, and exclusively use its data if it exists, and only fall back to /usr/lib/os-release if it is missing. Applications should not read data from both files at the same time. /usr/lib/os-release is the recommended place to store OS release information as part of vendor trees. /etc/os-release should be a relative symlink to /usr/lib/os-release, to provide compatibility with applications only looking at /etc/. A relative symlink instead of an absolute symlink is necessary to avoid breaking the link in a chroot or initrd environment such as dracut. os-release contains data that is defined by the operating system vendor and should generally not be changed by the administrator. As this file only encodes names and identifiers it should not be localized. The /etc/os-release and /usr/lib/os-release files might be symlinks to other files, but it is important that the file is available from earliest boot on, and hence must be located on the root file system. ``` So why not make sure `/etc/os-release` is a file and do this: dpkg-divert --add --local --no-rename /etc/os-release in the post processing step? Shouldn't this prevent any future base-files update from preventing to overwrite the `/etc/os-release`? The only issue I would see if someone performs a distribution upgrade and now the `/etc/os-release` no longer contains the correct version, but other than an apt.conf hook that updates `/etc/os-release` based on new information from `/usr/lib/os-release` after an upgrade, I don't see a way to do this automatically. I would rather divert '/etc/os-release' in a postprocessing script than `/usr/lib/os-release` because, I see the post-processing more of a local configuration. For multiple reasons we cannot used a package to write the version information, so that is out of the picture anyway. The only other way would be to create a new file just for the image or build version, but that would break compatibility now. regards, Claudius