From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6917993065941565440 X-Received: by 2002:a19:6b0d:: with SMTP id d13mr1094628lfa.63.1611308842369; Fri, 22 Jan 2021 01:47:22 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a2e:91c3:: with SMTP id u3ls1062249ljg.10.gmail; Fri, 22 Jan 2021 01:47:21 -0800 (PST) X-Google-Smtp-Source: ABdhPJxi5/jJ2ewP/T9eFrjOhxrddvv+iE3OOzTQN3XMk1xwDv4m7f9b68EhnBBXp0mH8+TIfhqG X-Received: by 2002:a2e:5408:: with SMTP id i8mr644535ljb.221.1611308841293; Fri, 22 Jan 2021 01:47:21 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1611308841; cv=pass; d=google.com; s=arc-20160816; b=I9GP92Yz1BPIN+8vBzqnjijI/DTk2IVG37RZsmjg8x0IsaeKEG6Or3gvw+V+JWMSXr vm99LyLnLrCYgIYYaKeR0wPzaWL2Bl7OID6NLpi90q5YJ4emWmWbWkXs15+KiN+mKk1G FvVuYj0wULMiL45Y+Gm7b93zTP7SWzKu+neGV4QP/wryW7u1/N9sg2SDvj/qUN/5fODA gkTMbjESWNjAcqxVTIPiE005lUK8zrF2BqG2nlCd1a/ZuEBL8dNRArVT+Aibj/Yn/4Nw BERVScHhyDZus0NF08u6gBmlJmB2F0dbFPUGVpOaNVdVFTcdnoU5tzbmrg2EyCZOOafe GC0A== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=mime-version:content-language:content-transfer-encoding:in-reply-to :user-agent:date:message-id:from:references:cc:to:subject :dkim-signature; bh=mMNb1uaJykWb2lkcPJlG3QcV1KPfaiUeNiFZrU3CZ2M=; b=bwy/EyDiCGC5lj4ht0m5E36JQJRjLHZkiPKWn4DC2VEA2N7SfWq+PeHX8OuEMsEUkE CztYMUja3eogyjyKKsgoL/bqb9SIliHmLCS1337hmBptyxmBtuuq/TdQMEbNQFSwnBV9 +kTzPuh53sdr4Fzm6ESxd54Bfo3MgYDn8yYS177lDuy79yD1+Sx6YxQWRa5v174Qr4vv k7ODH4hxkiws/8kjY9HWosBwgv4CpzNTC+XhQxX0dGlH2Lgxln3tCy68SYk2tEyIxdRf 6oQz96UTszgbpeXOwkSQ1m193gCIn+kYvN3l+V3MVV1lDmYWL3OVE8tLd6O6AzwS47lx pwMg== ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@siemens.onmicrosoft.com header.s=selector1-siemens-onmicrosoft-com header.b=n6a4nJbY; arc=pass (i=1 spf=pass spfdomain=siemens.com dkim=pass dkdomain=siemens.com dmarc=pass fromdomain=siemens.com); spf=pass (google.com: domain of silvano.cirujano-cuesta@siemens.com designates 40.107.3.57 as permitted sender) smtp.mailfrom=silvano.cirujano-cuesta@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Return-Path: Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30057.outbound.protection.outlook.com. [40.107.3.57]) by gmr-mx.google.com with ESMTPS id u24si373925lfo.1.2021.01.22.01.47.21 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 Jan 2021 01:47:21 -0800 (PST) Received-SPF: pass (google.com: domain of silvano.cirujano-cuesta@siemens.com designates 40.107.3.57 as permitted sender) client-ip=40.107.3.57; Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@siemens.onmicrosoft.com header.s=selector1-siemens-onmicrosoft-com header.b=n6a4nJbY; arc=pass (i=1 spf=pass spfdomain=siemens.com dkim=pass dkdomain=siemens.com dmarc=pass fromdomain=siemens.com); spf=pass (google.com: domain of silvano.cirujano-cuesta@siemens.com designates 40.107.3.57 as permitted sender) smtp.mailfrom=silvano.cirujano-cuesta@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FG1p2u4Qheejh+rdyYxVCFXejZ0VUOlrutm0kk1mqYyOgD17JMu1ZPeWyWmrr5pKFlL9DZRkRmfQdSZlJ+tI4s93ILWWLvvLouqCGlW4ld/mCyAKYesiPHJpIHu1nd1Rg3ztxAPcAjTqHGZGH2O6gWGQJ+a+TwukcrDF1lwEFxwHYaRD2OkqUiBdRvASFpXyjuzdWqPyMq7vzvN1+sxt0jFVdMsvVwRBLcc3ekpY58lqdSCNdq5UFG/sSpWJ+YGRad0HdKJnzV5CdTSr6tjEcX4PspJ2H4dQUPFd8Xmcyf5ba+ue/o1Qfz2mJeYZ8M70JJSafckxLAheZoNDzddNtg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mMNb1uaJykWb2lkcPJlG3QcV1KPfaiUeNiFZrU3CZ2M=; b=FXU0WiSy6V2GxMcuIGLXXmR3kxZWC9Re7C/1kHIzmJrcY3BolPVuLT5x6gaOzbI7IOZVKHxX6EmaePQEUfZB/OfxXkra9cqavin/9XB01I19WqeehKfthXRPctDn2ke7RK2OAWUGbdQt2JVfrhlefBL9PFLub657ocWc3h9RYw/uzB/3WbPoUpRXNoynt2x3Y/P0LLrc2w73BRBU71g2T07MYNENeAiQLhbLRLkJpMwf8pIBGqnmt/j8ydGhCqLnowlqe7EFXKrV0eCZcb/YclrhaiUHItn20Ukorx6kxMogrpn3WdfV1W2tsiarV5yIoIsnaOjAqB2PmsGEHTUvbg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=siemens.com; dmarc=pass action=none header.from=siemens.com; dkim=pass header.d=siemens.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=siemens.onmicrosoft.com; s=selector1-siemens-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mMNb1uaJykWb2lkcPJlG3QcV1KPfaiUeNiFZrU3CZ2M=; b=n6a4nJbYRj/Zhq9RNxJOiaKrxHfHssA1I0NY0tvNHY5gM44UNlBHstITG3QcqR1ardYLxobDyiJOEDPF5xG/v7XBkMC8F5JQIfmGQTZ0j5Ak9F905saMe1rlcT1xVV//33q0KFJMBvdsq1/rE9GQOym3L6+L4LwvD0oYceiKPO4= Authentication-Results: googlegroups.com; dkim=none (message not signed) header.d=none;googlegroups.com; dmarc=none action=none header.from=siemens.com; Received: from AM0PR10MB2708.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:208:12a::30) by AM8PR10MB4258.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:20b:1ea::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3784.13; Fri, 22 Jan 2021 09:47:20 +0000 Received: from AM0PR10MB2708.EURPRD10.PROD.OUTLOOK.COM ([fe80::c035:62d1:fd79:1bc8]) by AM0PR10MB2708.EURPRD10.PROD.OUTLOOK.COM ([fe80::c035:62d1:fd79:1bc8%5]) with mapi id 15.20.3742.012; Fri, 22 Jan 2021 09:47:20 +0000 Subject: Re: image-postproc-extension.bbclass modifying /etc/os-release To: Claudius Heine , 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> <402794f7-74a3-ab50-972e-7682d5388ff2@denx.de> From: Silvano Cirujano Cuesta Message-ID: <0beb8d2d-5141-647c-a831-8693276c957a@siemens.com> Date: Fri, 22 Jan 2021 10:47:12 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.1 In-Reply-To: <402794f7-74a3-ab50-972e-7682d5388ff2@denx.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-Originating-IP: [2001:a61:3ba9:3102:e458:f9ae:a68a:ac3d] X-ClientProxiedBy: AM4PR07CA0008.eurprd07.prod.outlook.com (2603:10a6:205:1::21) To AM0PR10MB2708.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:208:12a::30) Return-Path: silvano.cirujano-cuesta@siemens.com MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [IPv6:2001:a61:3ba9:3102:e458:f9ae:a68a:ac3d] (2001:a61:3ba9:3102:e458:f9ae:a68a:ac3d) by AM4PR07CA0008.eurprd07.prod.outlook.com (2603:10a6:205:1::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3805.5 via Frontend Transport; Fri, 22 Jan 2021 09:47:19 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: d6cd95b9-02fa-4a3f-db53-08d8bebab5ad X-MS-TrafficTypeDiagnostic: AM8PR10MB4258: X-LD-Processed: 38ae3bcd-9579-4fd4-adda-b42e1495d55a,ExtAddr X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: psdcTdKP6aWQlXjKXmgv0SEvmKQDfiyhl1BsIpwt2tthzsyb/IKD5k1hhRP8bspdvl1hty24HFoaqrQeyHp/xksmw7tTQ5lSAG2ifRxEegmOBwozYdBWfPCirlDz4+QhHVxmZnaKGpPf+FDDb5HkneI00nhgJbrU8zBpXSaSF1xovauYeTu0sUXwNL/rEsYrJLJlyEC6owCEhoKz47WSqDYu4jKd+5USkD4PkCLotsMnY9MN7BS/IP8dGRXFOX0eaHfD2FU3rl0iJlpF+NtuLcQCerYq7SAbrLxuXlDYz7/7D0x5Wpnns7aiUOMidBVz6CdUOkjCfOyOhwP4VjNgM/CqL1Con/3kIW7GMYnO/IVn37Wp57rT/7kQt3cG0ZM/b0n1gRBNPPINKWdqAa/lojUG9o1Ls9v74/uyAjvkgLTD01GuAf5XxEnWX4uvwXqQ1n7kDNpiwAx4uiIDUqOnTEldVYtgoMSuRKEOoJCOLOX5yEW6kP9nji1yZ79lQ2rWDpFP//M3k5lgbRrR5itnUiTAOhdoRocZlGaaM0ABLz5cYSY7FUrS/TwGVBKZ8naBa9ci7GQGN2wUiiAEWCwDTA== X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AM0PR10MB2708.EURPRD10.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(4636009)(366004)(376002)(346002)(396003)(136003)(39860400002)(66476007)(478600001)(83080400002)(16526019)(2616005)(8676002)(6636002)(110136005)(66556008)(186003)(53546011)(66946007)(316002)(8936002)(6666004)(5660300002)(4326008)(86362001)(36756003)(31686004)(83380400001)(2906002)(31696002)(966005)(6486002)(43740500002)(45980500001);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?d0RkZlUyeHAycFFlL3kxaHNrKzlRdmZJSG1ML2tIQy9rQ0U4Z2xqQlBlbitu?= =?utf-8?B?VU5Wa2FMY21LQ0srbzl1d0IrME42Nlh3NmtXbk96bnlaODcvY2xZUkhtWnJn?= =?utf-8?B?ejB4Z0ZrS3NSQ29oREdHeTdHUGczT1NBSEtKZUoxYllac21jWlpnMGo0a3Jh?= =?utf-8?B?bUxPbGhhMnJjOVd1TXdieHpBcGh2ZnpsY2s0WStiSkJ3ak9xS1ZpVXNVOFh4?= =?utf-8?B?cnNhVmFBd3QyMk8xUHVaYUZPT09GdEhiTER4MFp0S3FmRHZxeW56NWE1NnUx?= =?utf-8?B?UWY0RXZOMGdueUdlNjVBdjVWc0Fac3hNN21xazIyOUYxVzgzQ1BoM0lTYTkz?= =?utf-8?B?NTNaTW9ORDFsbGpSc2ZxU3lldWlVN2VXOXl1MHMwZ2s0K01ZWmwzN1VuRGp4?= =?utf-8?B?ZVVMc1NDU3FXRDByUy9INGRjMUN5bUduOTI3U1ZEUkp3VWtrNXRlSFRhWjhD?= =?utf-8?B?UG03VnlVY1ZKL1RvYjdPZEN1clU2NUJmV3ZRakJjTjl4aDkwYVhxdUZZdHV2?= =?utf-8?B?SEp0dGtsVnUxVlo4UHlsUHduc2cxVnRqaytYdTcxeEljL0szRnJldldpcW9v?= =?utf-8?B?WFpuQTZpbkljVEJqdnRLQ3dPU3Y4Zmo3QytJbGhOK3FhalJnK3BsL2FHL3VF?= =?utf-8?B?bEZuVDBrY09MWnZadndKcjBTUHRXV25lRis4NEM2QVhaMStzVkFJREMwdkli?= =?utf-8?B?WU5yQTFKSTUyZEpBY1ovV01mbWZQVC9HV2UzVmx4SnlnazZycnRBa05SVllz?= =?utf-8?B?a2liMTMwWlVSRGhMUjlFdmRQZUtsUTJHV0x3R29rUm5Zc0FycWt5UVhXVXVh?= =?utf-8?B?cFRYbXVQRG4rQVhDa0ZMS1MydGJvVjlqakhORjZtTXV2WjVWc2RxOFdjS0Jn?= =?utf-8?B?eHB6RkFBR0xlNHAvZnJZTEczMkJxNjVEVHVrWENMN2JKc0dvK0MvcWJUSGFp?= =?utf-8?B?RXhiYk9ER0N4Q3hNRUtmY0JGN3dPV3ZmSkdHemxvVHViVjlPT3Z6SExudFA3?= =?utf-8?B?bWp5d1VVbUxDd3QxZFlxSEd5VXdLQmIvTENtdG9hdlN5TGZCOVAwUDBjaFZ3?= =?utf-8?B?bksyZWt6d0w3bjNjT0tycDVEQzZSK3ZkQWJLME9TME40Z3A5aTBNMS8xMy9p?= =?utf-8?B?djY3bi9tbjUrTHZlczFaMmJpcHdmaUUydGlNczJVV2RHaklBb0RkNUNlSExr?= =?utf-8?B?Y04yKzdjZlJEVE9lR2I4L0lSTlJuZjNmdGpHSlVJZzRYOFh6N0MwVDJaTVdn?= =?utf-8?B?NEhSaUhCaENOZVBkSm5TbEZCZWV2dkRiTkg0OGZMeFJTanpTYnIrd2NybDZu?= =?utf-8?B?OU5HVW5PRXZLVEI2ekhJVVRZQTg1ZFd5dUJTRkZUem9LYzlMcEdBN1I4REZX?= =?utf-8?B?QThlL094eG5JL0JCYkYyV1B5RXFJOHEyenRMNU56V09BcGN4ZE5IanVIeUpN?= =?utf-8?Q?KMeMvZFS?= X-OriginatorOrg: siemens.com X-MS-Exchange-CrossTenant-Network-Message-Id: d6cd95b9-02fa-4a3f-db53-08d8bebab5ad X-MS-Exchange-CrossTenant-AuthSource: AM0PR10MB2708.EURPRD10.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Jan 2021 09:47:20.1325 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 38ae3bcd-9579-4fd4-adda-b42e1495d55a X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: XyWx2dgknMaILf2m4xML7lUI1F/2Z5WIAaEQSeCyZQ2TLWh1YeAmlqQg5+dIg6vktiePyalS3vhheHX2/EYeXTED6dCyR6mdUdIJccrTbIQz4yrl+JcbmgsiwiivOrpG X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM8PR10MB4258 X-TUID: AOVKlhZRZS6T 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-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: That's probably a misunderstanding. I don't mean that we have to create "a file", but provide the os-release information according the 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/lib/isar-release, no /usr/lib/os-release at all (it's not the recommended way, but it isn't forbidden either) ... > > ``` >        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`? This command would so to say command dpkg not to touch /etc/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 modifying/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-release and restoring the original one. 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 multiconfig and packages, this might be the only feasible solution... > > 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. Why should a distribution upgrade change that? I'm not aware that dist-upgrade changes file diversions... To my knowledge, once the file diversion has been created, dpkg should completely ignore that file. File diversions don't apply to packages, but to files, therefore 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 track of the file path and of the package that requested the file diversion (unless "--local" specified, as you propose). > > 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. Diverting /etc/os-release or /usr/lib/os-release depends on what we want to achieve (it would be even better letting the ISAR user decide it): 1. Keep originating Debian for reference? Then change only /etc/os-release. 2. Wipe away all information about originating Debian? Then change /usr/lib/os-release. /etc/os-release might appear like a local configuration for the ISAR builder, but IMO it's intrinsic information about the distribution being built with ISAR. As the documentation that you are quoting says "defined by the operating system vendor and should generally not be changed by the administrator." Therefore IMO the path /etc/os-release was kept for historical reasons (see footnote 1 of the announcement [1]), but it's an exception to the convention that files under "/etc" are configurations and can be changed. [1] http://0pointer.de/blog/projects/os-release > For multiple reasons we cannot used a package to write the 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 solution... Except for those people who wrote their own base-files package to resolve this issue, since their package won't work anymore :-) They would have to manage this file using hooks instead of directly declaring the file as managed by their package. > > 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 like /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 mention, but also because ISAR is de-facto creating a Debian Derivative that information belongs logically into /etc/os-release. Someone finding vanilla Debian inputs in /etc/os-release would expect a vanilla Debian installation, not an ISAR-built distro. > > regards, > Claudius   Silvano -- Siemens AG, T RDA IOT SES-DE Corporate Competence Center Embedded Linux