From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6917993065941565440 X-Received: by 2002:a05:6e02:1be6:: with SMTP id y6mr17726044ilv.145.1612850563125; Mon, 08 Feb 2021 22:02:43 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a92:4b06:: with SMTP id m6ls4628455ilg.0.gmail; Mon, 08 Feb 2021 22:02:42 -0800 (PST) X-Google-Smtp-Source: ABdhPJz8DnN2ka2y4Bw6dLwJdDtfTgXy0j5nIO4ZeHLBLzltlM/bXYM+LEnmwMPQwnMLnnmXBK/6 X-Received: by 2002:a92:ab10:: with SMTP id v16mr19499238ilh.100.1612850562445; Mon, 08 Feb 2021 22:02:42 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1612850562; cv=none; d=google.com; s=arc-20160816; b=g4EemffGPSq6mQWugLFuVI1q0wPPY8PdMBE/90jbPYNRjf7D7ixV6RNeMuKrL94huv UQIBEEcwHDZlWP0PIFCHew7pM89aqIm/rEpXWLUHFuEgH18fNwSE5zVEwAmoPmtJLk0N tHx0oMSUz7yPftKBNJts9ZL6UMtRak01yqQ66FBrM3yX2LrzISkDPRqa54Qoyrhia5Ug jpN3vuiiDFFdlPnDA5sRvBm3upOSOhc3PAYrTquJRJhAFr3b2PgbtSEYaeppgd8FDOy3 Qs3Ok5HnxvAAUqsi8OvqzJpu4VN58vFUuCzpPTri/P3esZeUjdHq5bsXbPYKMJhDCjdI dYPg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=k96S/rJPBw9ReHoDkN8sKbeEotumLbzQzRV77sZbvNU=; b=FgIZwzt9rMHVWnraqHv0ZXJoN4fhrDU/qa2bX/mM4CMTN4WkuSxbK+RNlZP1/KTsnb OKC5STc1CCZ14q91ZTgRyDjVe2L5LPHq/O9Y/GC7kQT7/JHGMKGa3wL80jmYWNpO/7UL NSXnjVsD5N+E2s0+EjZa5aH2aoKcDp5SIGJz7rTRmzhb/qPYC1hSctCB4TMUkX5Bqt+L +pLBckAfq9BZKas2TDvkBQ5zIe8FItfdCIfIK5s6I5BJEFNKY4vBWY6EYlO1D0dM7rCu BhD7DQAChX1hv18cprilmnQsHyPYMR0qIZDfUYqokZ0747n22/INf0DQek11RrFouMHr oqEw== ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=qszV6LWC; spf=pass (google.com: domain of vijaikumar.kanagarajan@gmail.com designates 2607:f8b0:4864:20::82a as permitted sender) smtp.mailfrom=vijaikumar.kanagarajan@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com. [2607:f8b0:4864:20::82a]) by gmr-mx.google.com with ESMTPS id 207si822179ioc.2.2021.02.08.22.02.42 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 08 Feb 2021 22:02:42 -0800 (PST) Received-SPF: pass (google.com: domain of vijaikumar.kanagarajan@gmail.com designates 2607:f8b0:4864:20::82a as permitted sender) client-ip=2607:f8b0:4864:20::82a; Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=qszV6LWC; spf=pass (google.com: domain of vijaikumar.kanagarajan@gmail.com designates 2607:f8b0:4864:20::82a as permitted sender) smtp.mailfrom=vijaikumar.kanagarajan@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: by mail-qt1-x82a.google.com with SMTP id c1so12252537qtc.1 for ; Mon, 08 Feb 2021 22:02:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=k96S/rJPBw9ReHoDkN8sKbeEotumLbzQzRV77sZbvNU=; b=qszV6LWCiUIbI+DQ8D/0uVMplzEE8hkeDSHlvsMPoq0Kmhnk9O1/eFU3xw3wZVLGrt i5m4HI8COCO3Mh50JsAK/yQB4R3PjGVxys5dtTkMkZw1A6JmjSt94bJt9/VBYLnfevOw xh45sVCwAIgXKoVAuVRgX1FuxKb7cCXAhKtQxFX+D4++K5STmuzQC9g6el/83xRUZ6MB GdoNpS6Pj74UzAStS9WpLbgDQurD2O4F6VfoNbzZU9k4MbTB9bUpTSutrRsw7K8u+l/U O6jP0NdyFrPF5FNsgtADa9Xi7tdKWW5eeRSxaYX2E+161NOCmScVWAHfaX9+QRh99Q19 CPLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=k96S/rJPBw9ReHoDkN8sKbeEotumLbzQzRV77sZbvNU=; b=d9+eBfnAIxyIQRmZdYDyhiSv9QZJyKnmUl0oTc0pJC54/rAp9P1q1qIuGtwWDzD45Z o4aouuiwJ4mUyQqjd/KkmtS2IDxyjkTH6woh0vGSzsMiZJl+/9fer7ZMpdXn3g6Hgex8 pAZ6rmKrexZmaOkO4p7+XXD0paScngaEyE9F+SfMl0o0WN8FqiKv3KJsMNkBhjqnKoE/ fJYpXiKTeYdh2gaGG2UvYzWTSCjFTyKCC7au99RgvX8K4ZSak9ABKdQ6PDDES9KY3SVV mxYwMqtu+sgyEfqZJvU1vfj4RrcFxFncHDZHfRok6tpEELfdjPCM7BkCAwtI9GjfLep5 g/WQ== X-Gm-Message-State: AOAM531tZYgGoOeuQjPeH/fUmgkOvzZx+NZSbaBVIOjCZVqaZsfK+c2J yD3aSIZS64kbcCRRzIBUWfkwAusfSbgBzyrydnfW6KijPxhp3g== X-Received: by 2002:ac8:508:: with SMTP id u8mr19500713qtg.138.1612850561534; Mon, 08 Feb 2021 22:02:41 -0800 (PST) MIME-Version: 1.0 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> <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> In-Reply-To: <3bbb9c63-6f3c-d0c9-416e-31edb430642f@siemens.com> From: vijai kumar Date: Tue, 9 Feb 2021 11:32:30 +0530 Message-ID: Subject: Re: image-postproc-extension.bbclass modifying /etc/os-release To: Silvano Cirujano Cuesta Cc: isar-users Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-TUID: ibIlrhadiLja On Mon, Feb 8, 2021 at 2:20 PM Silvano Cirujano Cuesta wrote: > > > On 07/02/2021 10:02, vijai kumar wrote: > > > > > > On Fri, Feb 5, 2021 at 8:27 PM Silvano Cirujano Cuesta > wrote: > > > > Hi Vijai, > > > > I like your proposal. > > > > 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 we keep the current broken implementation. We shoul= d fix it. > > > > > > > > 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 info= rmation is purely build-system related, should we try to put it in a packag= e? Does this file need updates in the future? Well, fro"m the current stand= point, 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= a cached apt-repo generated with ISAR using some other tool, this info is = not relevant. > > You possibly miss my explanation why simply placing that file there on po= st-processing is an error: any package-update of base-files would overwrite= that file with the Debian vanilla one. In order to avoid that file from be= ing changed on package updates we need to create either a file diversion or= package replacement (like Ubuntu does). Ah, In the above I was merely talking about the information (i.e the ISAR version, commit info etc.) regardless of where it is put. 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. > > BTW, a package doing only "dkpg-divert" for /etc/os-release doesn't need = to contain any version information. Then the version information can be add= ed on image postprocessing. That would be a compromise, because it wouldn't= break any package caching. > > I don't know exactly how caching works, but I wonder which caching would = be breaking just because a package changes. Cached packages? Cached rootfs?= Cached images? I would expect almost all rebuilds to be modifying images. = I would also expect most of the rebuilds to be modifying the rootfs. Please= correct me, if I'm wrong. > > > > > 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 nee= d to know why? So that we know how costly it is to break backward compatibi= lity. Huge or none at all? > > I'm sort of part of that community :-) I get here from a project where we= are using ISAR. A provider of us identified the above mentioned issue and = fixed it on one of their layers replacing base-files with their own version= , what I consider the right fix, but still a fix of something broken in ISA= R. But being myself also a (small) contributor of ISAR I decided to address= the issue upstream. > > Back to your "real-life scenario" question. We started using it because t= hat what the place to identify which base-system release we hat while integ= rating other components on the system. Moving that information to a file li= ke "/etc/isar-release" would fix it for us, we would simply have to update = our integration to fetch the information from that file. > > Here start my personal opinion, nothing to do with my "real-time scenario= ". ISAR is being used in multiple cases to build Debian-derivates [1] and I= would expect a Debian-derivative to provide some hint about it in its /etc= /os-release. Therefore I would like to see ISAR providing the means to easi= ly accomplish it. But since I seam to be the only one seeing that need, I m= ight try to convince you with a RFC patch :-) 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. Thanks, Vijai Kumar K > > [1] https://www.debian.org/derivatives/ > > Silvano > > > > > Thanks, > > VIjai Kumar K > > > > > > > > Ciao, > > > > Silvano > > > > On 05/02/2021 12:55, vijaikumar....@gmail.com wrote: > > > Hi All, > > > > > > On Friday, January 22, 2021 at 5:06:34 PM UTC+5:30 Silvano Ciruja= no Cuesta wrote: > > > > > > Hi Claudius, > > > > > > On 22/01/2021 11:33, Claudius Heine wrote: > > > > Hi Silvano > > > > > > > > On 2021-01-22 10:47, Silvano Cirujano Cuesta wrote: > > > >> Hi Claudius, > > > >> > > > >> TL;DR: you're proposing here what appears to be a feasible= solution to this issue without using a package > > > >> > > > >> Nevertheless, more information inline. > > > >> > > > >> On 22/01/2021 09:52, Claudius Heine wrote: > > > >>> Hi Silvano, > > > >>> > > > >>> On 2021-01-19 11:37, Silvano Cirujano Cuesta wrote: > > > >>>> We can create a removal file diversion for /usr/lib/os-r= elease (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-fi= les" package) we can do pretty much the same: > > > >>>> > > > >>>> - the package doesn't provide /usr/lib/os-release, leavi= ng it package-unmanaged > > > >>>> > > > >>>> - image post-processing to create the file becomes a req= uirement > > > >>> I looked at the manpage of os-release and it does not sta= te that `/etc/os-release` can or should not be a file: > > > >> > > > >> That's probably a misunderstanding. I don't mean that we h= ave to create "a file", but provide the os-release information according th= e specification. There are multiple different valid combinations: > > > >> > > > >> - /etc/os-release symlink to /usr/lib/os-release > > > >> > > > >> - /usr/lib/os-relase only (not /etc/os-release at all) > > > >> > > > >> - /etc/os-release only, no /usr/lib/os-release at all (it'= s not the recommended way, but it isn't forbidden either) > > > >> > > > >> - /etc/os-release is a symlink to another file like /usr/l= ib/isar-release, no /usr/lib/os-release at all (it's not the recommended wa= y, but it isn't forbidden either) > > > > > > > > Well I had this in mind: > > > > > > > > - /etc/os-release is a file containing the isar version, = /usr/lib/os-release is a file containing the original debian version as dep= loyed by base-files. > > > > > > > > This could also be done similar to your fourth solution: > > > > > > > > - /etc/os-release is a symlink to another file like /usr/li= b/isar-release, original /usr/lib/os-release from base-files > > > > > > > > The manual page states that /etc/os-release takes precedenc= e over /usr/lib/os-release, so if /etc/os-release exists, it does not matte= r if /usr/lib/os-release does as well or what its content is. > > > I also had foreseen that option as one of my favorites (eithe= r that or the first one), therefore that would be fine for me. > > > > > > > >> > > > >> ... > > > >> > > > >>> > > > >>> ``` > > > >>> The file /etc/os-release takes precedence over /u= sr/lib/os-release. Applications should check for the former, and exclusivel= y 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 p= lace 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 o= perating system vendor and should generally not be changed by the administr= ator. > > > >>> > > > >>> As this file only encodes names and identifiers i= t 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 ava= ilable 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 t= his: > > > >>> > > > >>> dpkg-divert --add --local --no-rename /etc/os-releas= e > > > >>> > > > >>> in the post processing step? Shouldn't this prevent any f= uture base-files update from preventing to overwrite the `/etc/os-release`? > > > >> > > > >> This command would so to say command dpkg not to touch /et= c/os-release from the point it's executed on. That way you can have a local= version of /etc/os-release and be sure that no package updates is modifyin= g/replacing it. Such a command would go into the postinst hook and another = postrm hook would be required to remove the file diversion for /etc/os-rele= ase and restoring the original one. > > > > > > > > Why would such a command go into a postinst hook? It contai= ns '--local' therefore I would expect the administrator doing it him or her= self. Or in Isars case a bitbake post installation process. > > > Sorry, forgot that we cannot use a package. A bitbake post in= stallation process is what I had in mind. I don't care in this mailing list= about admins "doing stuff" that might break their systems ;-) > > > > > > > >> > > > >> This would technically resolve the issue, but looks a bit = weird to me. Debian and derivatives get that file managed by a package. But= since I haven't understood what the issue mentioned by Henning regarding m= ulticonfig and packages, this might be the only feasible solution... > > > > > > > > Simple example: Our /etc/os-release contains the build date= and git commit id. If we put this information into a package, then it we c= ould not cache it, because this information will change constantly. That al= so means all dependent tasks and recipes (image creation) cannot be cached,= breaking the caching of a lot of stuff. > > > > > > > > Calling 'bitbake isar-image' two times in short succession = without any change, would cause 2 full builds of the whole image. > > > The current image post-processing is happening pretty much in= the end and not breaking caching, right? Wouldn't it be possible to modify= /extend that recipe to create a Debian package and install it chrooting to = the root filesystem? > > > > > > > >>> The only issue I would see if someone performs a distribu= tion upgrade and now the `/etc/os-release` no longer contains the correct v= ersion, but other than an apt.conf hook that updates `/etc/os-release` base= d on new information from `/usr/lib/os-release` after an upgrade, I don't s= ee a way to do this automatically. > > > >> > > > >> Why should a distribution upgrade change that? I'm not awa= re that dist-upgrade changes file diversions... To my knowledge, once the f= ile diversion has been created, dpkg should completely ignore that file. > > > >> > > > >> File diversions don't apply to packages, but to files, the= refore I'd expect it to survive a dist-upgrade. Therefore dpkg doesn't keep= track of the packages that are "blocked" from touching a file. It keeps tr= ack of the file path and of the package that requested the file diversion (= unless "--local" specified, as you propose). > > > > > > > > You misunderstood me. > > > > > > > > In my example a base-files package would still update /usr/= lib/os-release to contain a new debian suite name, if you do a distribution= update. If you want our diverted /etc/os-release to contain this new info = automatically, you could do this via a apt.conf.d hook. > > > Diverting only /etc/os-release you get /usr/lib/os-release ma= naged (and therefore updated) by base-files and ISAR takes care of /etc/os-= release. I don't understand the need for an apt.conf.d hook... ISAR creates= it and adds it to the root filesystem relying on neither the user nor dpkg= modifying it. > > > > > > > >> > > > >>> > > > >>> I would rather divert '/etc/os-release' in a postprocessi= ng script than `/usr/lib/os-release` because, I see the post-processing mor= e of a local configuration. > > > >> > > > >> Diverting /etc/os-release or /usr/lib/os-release depends o= n what we want to achieve (it would be even better letting the ISAR user de= cide it): > > > > > > > > I don't want to divert /usr/lib/os-release. Let it contain = the upstream version for reference. This file does not matter, because /etc= /os-release takes precedence over it. > > > Hopefully it's clear from my comments above, that I find this= approach fine. > > > > > > > >> > > > >> 1. Keep originating Debian for reference? Then change only= /etc/os-release. > > > > > > > > Yes. > > > > > > > >> > > > >> 2. Wipe away all information about originating Debian? The= n change /usr/lib/os-release. > > > > > > > > No. > > > > > > > >> > > > >> /etc/os-release might appear like a local configuration fo= r the ISAR builder, but IMO it's intrinsic information about the distributi= on being built with ISAR. As the documentation that you are quoting says "d= efined by the operating system vendor and should generally not be changed b= y the administrator." Therefore IMO the path /etc/os-release was kept for h= istorical reasons (see footnote 1 of the announcement [1]), but it's an exc= eption to the convention that files under "/etc" are configurations and can= be changed. > > > > > > > > Well its a separate discussion if Isar is in the role of a = distribution vendor or of an administrator. > > > > > > Is this a philosophical discussion? :-) Am I making a fuss? > > > > > > I might have a different understanding for "admin", but if no= t distribution builder, I'd say installation builder, but not administrator= . > > > > > > IMO ISAR is a distribution builder and as such a tool for dis= tribution vendors. As a Debian user I find at home with many ISAR images, b= ut not at all with some others. > > > > > > A distribution according this definition "A Linux distributio= n may also be described as a particular assortment of application and utili= ty software [...], packaged together with the Linux kernel in such a way th= at its capabilities meet the needs of many users.", taken from https://en.w= ikipedia.org/wiki/Linux_distribution > > > > > > > > > > > > > > I would say its something in between. > > > > > > > >> > > > >> [1] https://eur01.safelinks.protection.outlook.com/?url=3D= http%3A%2F%2F0pointer.de%2Fblog%2Fprojects%2Fos-release&data=3D04%7C01%= 7Csilvano.cirujano-cuesta%40siemens.com%7C4348b0c7cf544189355608d8bec12a38%= 7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637469084129831158%7CUnknown%7= CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn= 0%3D%7C1000&sdata=3Dgobc49NK4Zh02%2BrVOBBU%2BQMg7sAu5XVstVzu39CquOA%3D&= amp;reserved=3D0 > > > > > > >> > > > >>> For multiple reasons we cannot used a package to write th= e version information, so that is out of the picture anyway. > > > >> As said above, if for the reasons you and Henning mention = using a package is out of the picture, this is probably the only feasible s= olution... Except for those people who wrote their own base-files package t= o resolve this issue, since their package won't work anymore :-) They would= have to manage this file using hooks instead of directly declaring the fil= e as managed by their package. > > > > > > > > This was why I proposed a apt.conf.d hook. Maybe we could g= enerally do it like this. > > > No matter how you divert that file (bitbake post processing, = apt.conf.d hook,...) the mentioned conflict with vendor-provided base-files= packages appear whenever you have a file divert. Unless that vendor-provid= ed base-files package modifies the file diversion being applied by ISAR (I = don't know if it's possible) to become the owner of the file. > > > > > > > > Some package changes /usr/lib/os-release and a apt.conf.d h= ook would merge this content with ours into /etc/os-release. > > > I still don't get the need for such "black magic". > > > > > > > >>> > > > >>> The only other way would be to create a new file just for= the image or build version, but that would break compatibility now. > > > >> Do you mean using a completely different file? Something l= ike /etc/isar-release or /usr/lib/isar-release? If that's what you mean, I = wouldn't do it. Not only because of the compatibility issue that you mentio= n, but also because ISAR is de-facto creating a Debian Derivative that info= rmation belongs logically into /etc/os-release. Someone finding vanilla Deb= ian inputs in /etc/os-release would expect a vanilla Debian installation, n= ot an ISAR-built distro. > > > > > > > > While I agree that Isar in some configurations creates a De= bian Derivative, currently it puts image version and build date into /etc/o= s-release. Which is strictly speaking not the right place for that. > > > If the image version and build date are relevant to have a cl= ear identification of the OS version, then I disagree. If that's informativ= e and not needed to have a unique identification of the OS version, then I = agree that it could be somewhere else (although I still think it's not a wr= ong place for it). > > > > > > > > It would be better to have something like /etc/base-image-v= ersion etc. for that. > > > > > > > > > > > > > After going through this, I feel that we could move the ISAR syst= em details to a separate file like /etc/isar_{version/base/info}. > > > ISAR, as I see could be used to create a custom distribution or i= n a simple case just the functions of what an installer would do in other > > > distribution(bootstrap and prepare a simple bootable image for(*a= nd) install). > > > > > > If we see the minimal case, it does not make sense to have the IS= AR info in /etc/os-release. And probably we should leave the /etc/os-releas= e > > > alone; at least in the main ISAR repo and leave the custom config= uration part to the users. In this way, we are not enforcing any uncommon > > > behavior (dpkg-divert+hook) that a new user least expects in ISAR= in its vanilla form. This leaves more freedom to the downstream users to > > > choose a method(custom base-files / dpkg-divert / any unofficial = way) that best fits their need based on what and where they need the inform= ation. > > > > > > If you have built an image with ISAR, you could find some details= about the ISAR system used from the /etc/isar_{version/base/info}. If you = want to > > > add more information to it, well you are free to do so. If you fe= el the information is crucial, that it needs to be present in /etc/os-relea= se, and > > > willing to maintain it for your custom distro, well you could do = it too. If you feel it is unnecessary, well you could remove it too. > > > > > > And then comes the discussion of backward compatibility. Probably= implement and maintain dpkg-divert approach and provide a way for existing= users to switch to them using a flag/feature. > > > > > > Thanks, > > > Vijai Kumar K > > > > > > > regards, > > > > Claudius > > > Silvano > > > > > > -- > > > Siemens AG, T RDA IOT SES-DE > > > Corporate Competence Center Embedded Linux > > > > > > -- > > > You received this message because you are subscribed to the Googl= e Groups "isar-users" group. > > > To unsubscribe from this group and stop receiving emails from it,= send an email to isar-users+unsubscribe@googlegroups.com >. > > > To view this discussion on the web visit https://groups.google.co= m/d/msgid/isar-users/6f4b945f-7763-49ee-a8c5-2e02d450a2e0n%40googlegroups.c= om > > > >. > >