From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6917993065941565440 X-Received: by 2002:a2e:7815:: with SMTP id t21mr1441796ljc.94.1612948972927; Wed, 10 Feb 2021 01:22:52 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 2002:ac2:4adc:: with SMTP id m28ls884539lfp.0.gmail; Wed, 10 Feb 2021 01:22:52 -0800 (PST) X-Google-Smtp-Source: ABdhPJzTAs7kYrFYfaGoJvatkGXFR3pfr7HSlhA2+UFPO1M7cfI6++p73DaFJW4r9NLzX3GcEv1v X-Received: by 2002:a05:6512:34d0:: with SMTP id w16mr1182855lfr.416.1612948972049; Wed, 10 Feb 2021 01:22:52 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1612948972; cv=none; d=google.com; s=arc-20160816; b=S/26fAqRO3f47rOAoLeZdGGQBiofur3q8sg+Rdb4uDVhz3ELedeZu5B0wASLnYO4O+ f3K7tAOngkbO9FwnUS2BSy/PAaY5rHdxvfoL1qx0fh6juvZD4GmQJha3ziETjiRdq+z8 f/Kb1QNLCqJxjQ7aqWlTNrV0Ri1keOVki6KV1EAlvGYw1dmjKmT6sa6MfL2RAj2Hq3az BNy1OnRhWrDo7nHIWRAFS7/3THjqn/2pkJSojIN1oJMb/u6fQFpSJrCpIrtNf2dRx7Ur JK43lzX8Ck3ieFtZhxh86aYBOj0h8fAW9E59gP5+RcLLPVYIZaJlwjoW5bkeNr/svPW3 Rjsg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=user-agent:in-reply-to:content-disposition:mime-version:references :mail-followup-to:message-id:subject:to:from:date; bh=SI9cYg2+BJJ0mtLFL+tMv1CjL/hHQgfMFpF2uPwcs1g=; b=vtkIEx1MmBRm0wsN87VCMw5E4G7DwX+cAXRLyx58883hCsngNN/hUJSyyQSR25Mb+x Qbeg4CXhVhADESyQ+pIgPM8tKsAPNScd0neZPCBGWqf2/DfqFH8DcGcXUw7OwUZ7oexc vOJa32tVwt2/YPy+923+zzEcrpbW9wz7/XOue3qMvfByZUsDk1Iv5UHySSHC3n5h3Ibp bIlMa6xmdubu6fFIyrgUSjvLxHSxJYEs+FtiXkyhwEiPLy8e6MbrwdFPQHw3sL3rONLf Nuy3b6PZ2RakG8CIKTmVqlSOx+/wj6Q6MsL3JiaICoZ35zyAJwIkGeu/Eq0IGmIb+WSn LB6g== 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 l22si45468ljh.4.2021.02.10.01.22.51 for (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Wed, 10 Feb 2021 01:22:51 -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 11A9MmiE011809 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 10 Feb 2021 10:22:51 +0100 Date: Wed, 10 Feb 2021 10:22:48 +0100 From: Baurzhan Ismagulov To: isar-users Subject: Re: image-postproc-extension.bbclass modifying /etc/os-release Message-ID: <20210210092248.GX20742@yssyq.m.ilbers.de> Mail-Followup-To: isar-users References: <12759268-1ad7-168a-dde9-4f2658567af1@siemens.com> <402794f7-74a3-ab50-972e-7682d5388ff2@denx.de> <0beb8d2d-5141-647c-a831-8693276c957a@siemens.com> <333bd498-2e79-bb2d-ef84-3f6ab68a68b9@denx.de> <6f4b945f-7763-49ee-a8c5-2e02d450a2e0n@googlegroups.com> <6473666c-a754-0512-0000-a072f4530d3f@siemens.com> <3bbb9c63-6f3c-d0c9-416e-31edb430642f@siemens.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: EH6VEJ+NE5P2 On Sun, Feb 07, 2021 at 12:31:23AM -0800, vijaikumar....@gmail.com wrote: > > If we need to provide "something" that keeps modifying the /etc/os-release > > for backwards compatibility, do we want to keep the current "broken" > > implementation? > > I would not suggest keeping it as it is. We know it is broken. Better to > fix it. I suggest to patch /usr/lib/os-release as the first step to preserve the /etc/os-release symlink (we could provide a patch), then see whether we want to optionally provide base-files in Isar. > > If we want to "fix" that implementation, then we can do it in a way that > > not only provides that backwards compatibility, but also to provides a > > useful feature. The default would be not touching /etc/os-release and one > > recipe could provide (when requested with a flag) a package for "managing" > > /etc/os-release (assuming it can be somehow accomplished with multiconfigs, > > or be a mutually exclusive feature). > > > > As Claudius previously mentioned, this might break caching. If the > information is purely build-system related, should we try to put it in a > package? Does this file need updates in the future? Well, from the current > standpoint, I don't see it needing updates. The data is only applicable > when we build using ISAR. If hypothetically, we decided to recreate the > distro with the cached apt-repo generated with ISAR using some other tool, > this info is not relevant. Under "caching" I understand base-apt. Providing base-files in Isar shouldn't break base-apt. Isar-generated base-files would land in isar-apt. Updating that file again and again with every new build is a normal project lifecycle. > That said, we need to understand from the community, what are the real-life > scenarios they are using this ISAR information in /etc/os-release for? I am > not personally using that info. If it is being used somewhere, we need to > know why? So that we know how costly it is to break backward compatibility. > Huge or none at all? I only use it visually when I log into the target. On Tue, Feb 09, 2021 at 11:32:30AM +0530, vijai kumar wrote: > I do > agree that the current way of changing the content of /etc/os-release > is an error, since now we know that it belongs to base-files and its > update makes that information disappear. While I agree that patching os-release is not optimal, overwriting on upgrade being a bug or not depends IMHO on whether a downstream declares itself a distro or not. If they don't, let Debian overwrite it -- it isn't an Isar-generated image anymore. If they do, they should provide their own base-files. > Agreed. /etc/os-release is supposed to be extendable. And looks like > there is no hard and fast rule which describes what is "OS > information". It could be accomplished by modifying base-files. I > would recommend ISAR support something similar to it instead of > bringing in a new package to handle /etc/os-release, which by the way > is redundant. If this is about providing base-files in Isar, I'm open to the discussion. A modified package would be cleaner than patching the rootfs. That said, my itch isn't currently that strong to provide a patch :) . With kind regards, Baurzhan.