From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6917993065941565440 X-Received: by 2002:a2e:878d:: with SMTP id n13mr4293199lji.382.1612804830969; Mon, 08 Feb 2021 09:20:30 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a2e:8952:: with SMTP id b18ls3059704ljk.3.gmail; Mon, 08 Feb 2021 09:20:29 -0800 (PST) X-Google-Smtp-Source: ABdhPJx9UMbf+PMdwHlpLiNRazJIdOpHGCmMsaxYmvaMObeWfVS4+RF/3nEO6LAUCea98MZjcdLW X-Received: by 2002:a2e:501e:: with SMTP id e30mr6263204ljb.317.1612804829748; Mon, 08 Feb 2021 09:20:29 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1612804829; cv=none; d=google.com; s=arc-20160816; b=BI+ZJkR4RLMV3cWzwaKlO5UCkx/ZzcXKPJV5e/GYLRqZNkVqE8OUvhI3fMF0UIbOYX 1inK7s8323V+15gV1K/unJZtebstqww06q0j2IVLgERoClQZxiFoYn0c23mWCkuyV7y2 WdkOHMSE4U5Cjs4pR/iJ7TSVlKlBw3YLpVMe1DnZhr9/PL4HvtDpIR0TM3y/2mUOQwrI EVLu6vh78m+joRT7ypx1KrUJe9MYSfiqkMGgYR8GcfRX2SYmFSHbulKDu2gM7yJDuXwW DJt0WtebEBoUzZC3ABZyysV5SBXFxwFFj7JXThThxhq3fBfRNdGCOwdKPAxlAgH8diqm ZzyQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=user-agent:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:mail-followup-to :message-id:subject:to:from:date; bh=hFq8NrKnhYKmGsu+vWm0KvhIOipkFHS0xxoqSwOl6Xc=; b=H4buyIzhFnjRRFlteDwak5dwQSaqDyLjgUAo8Ub7j6p0YpLa3rPMCPi+lzWY2a7fw0 DODjGBqn4ZtSlPkzWxlvbzVy+f35jSjixRqavLJ+SYAM4oiU885I/WzXWiX6w8I70GwL a2nQ3O4Ueh/4qhVtKwZSUQa1zSrXtECqJTREwdSd8S0aT5usiwZb4hBWLdFk84FAm/PU lsyHcFmZ8KGZqYcQo7mNEu3+hcD0Ng5/mVzDtajq0lX68PdROV9YaeQpe5HhYA7vpQoA SVYhpsfmIig3EIvsuswCOhu9hchub457jGULOZmyvXZiots1ehp4VTMjvMbImDDg8VdB QQnQ== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=neutral (google.com: 85.214.156.166 is neither permitted nor denied by best guess record for domain of ibr@radix50.net) smtp.mailfrom=ibr@radix50.net Return-Path: Received: from shymkent.ilbers.de (shymkent.ilbers.de. [85.214.156.166]) by gmr-mx.google.com with ESMTPS id c6si1021314ljk.2.2021.02.08.09.20.29 for (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Mon, 08 Feb 2021 09:20:29 -0800 (PST) Received-SPF: neutral (google.com: 85.214.156.166 is neither permitted nor denied by best guess record for domain of ibr@radix50.net) client-ip=85.214.156.166; Authentication-Results: gmr-mx.google.com; spf=neutral (google.com: 85.214.156.166 is neither permitted nor denied by best guess record for domain of ibr@radix50.net) smtp.mailfrom=ibr@radix50.net Received: from yssyq.m.ilbers.de (host-80-81-17-52.static.customer.m-online.net [80.81.17.52]) (authenticated bits=0) by shymkent.ilbers.de (8.15.2/8.15.2/Debian-8) with ESMTPSA id 118HKQS6003712 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 8 Feb 2021 18:20:28 +0100 Date: Mon, 8 Feb 2021 18:20:26 +0100 From: Baurzhan Ismagulov To: isar-users@googlegroups.com Subject: Re: image-postproc-extension.bbclass modifying /etc/os-release Message-ID: <20210208172025.GT20742@yssyq.m.ilbers.de> Mail-Followup-To: isar-users@googlegroups.com References: <67e1fac9-5af5-29aa-de57-9a0de0cdd165@siemens.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-9 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <67e1fac9-5af5-29aa-de57-9a0de0cdd165@siemens.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on shymkent.ilbers.de X-TUID: CChnkWCDfnE6 Hello Silvano, On Fri, Jan 15, 2021 at 03:26:14PM +0100, Silvano Cirujano Cuesta wrote: > I've noticed that '/etc/os-release' is being changed on the image in meta/classes/image-postproc-extension.bbclass [1].� What BTW ends up changing '/usr/lib/os-release', since it's only a symlink. But both '/etc/os-release' and '/usr/lib/os-release' are owned by 'base-files'... > > An upgrade of 'base-files' would be replacing (silently, since is not marked as a configuration file) '/usr/lib/os-release' with the version of the upstream 'base-files' package and possibly breaking any tools in the system relying on certain values in that file. > > Is there a reason that I'm missing for doing so instead of the Debian-way (file diversion with dpkg-divert)? Or any hack that I've overseen that avoids the mentioned breakage? Thanks for raising this topic. I'd like to address some of the issues. * I see identification as a downstream issue. However, it would be nice to provide something by default. Thus we touch os-release. * Regarding an Isar-specific identification file: This is advised against in http://0pointer.de/blog/projects/os-release.html. * Breaking /etc/os-release -> ../usr/lib/os-release is a bug. We should modify /usr/lib/os-release, in whatever way. We should not break the symlink. I agree we should fix this. * Isar was conceived as a rootfs builder that should be able to work without creating a derivative (remember SLIND). If a downstream feels like it, they may create a derivative. * For a given rootfs, the identification information is intrinsically static. Thus, the best would be to provide it in a static way, e.g. by patching (the current approach) or providing base-files (I see this as a downstream issue). * os-release contains static information and doesn't have user-modifiable contents. Thus, I agree with Debian that this is not a config file. * Upgrading base-files would overwrite os-release. From Isar point of view, I'm fine with that; after all, it isn't the original image, it's image + upgrade -- the identification should be changed as well. * If a downstream wants to preserve the identification through package upgrades, they should provide their own base-files. Maybe we could make it easier for them in stock Isar. * Since the information is static, dynamic approaches (config files, postinst, alternatives, diversions) are not necessary. They are more complex than they seem at the first glance (package upgrade order, package removal order, downgrades, failed upgrades, idempotency, etc.). To summarize, I suggest fixing /etc/os-release -> ../usr/lib/os-release symlink breakage. If there is an itch for the upgrade problem, I'd be open for the discussion on providing base-files with Isar. With kind regards, Baurzhan.