From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Fri, 06 Dec 2024 04:38:40 +0100 Received: from metis.whiteo.stw.pengutronix.de ([2a0a:edc0:2:b01:1d::104]) by lore.white.stw.pengutronix.de with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1tJPAt-004aDo-1Z for lore@lore.pengutronix.de; Fri, 06 Dec 2024 04:38:40 +0100 Received: from localhost ([127.0.0.1] helo=metis.whiteo.stw.pengutronix.de) by metis.whiteo.stw.pengutronix.de with esmtp (Exim 4.92) (envelope-from ) id 1tJPAt-00018F-Io; Fri, 06 Dec 2024 04:38:39 +0100 Received: from mail-pj1-x1031.google.com ([2607:f8b0:4864:20::1031]) by metis.whiteo.stw.pengutronix.de with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1tJPAi-00017q-47 for rauc@pengutronix.de; Fri, 06 Dec 2024 04:38:28 +0100 Received: by mail-pj1-x1031.google.com with SMTP id 98e67ed59e1d1-2ef10b314e4so1403622a91.0 for ; Thu, 05 Dec 2024 19:38:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1733456305; x=1734061105; darn=pengutronix.de; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=yapDheH9AE3cY7SG3Bmd2k0N02t4sOTFZafr3pCQcdA=; b=MGBOKHecfNCY5qa6qnYLR7f9KKQDCHTcTgYwU9oal7I4o21qIGvxeNiPbKZ7nJU7NU IkqDKLUz1kiILMivOLeKXHSQbuTPSWXFxe7bBsewFyN838JrxMJHswn7eA9QmsQXIrjv R5/hEvwpMDodlgSxxubsEvZUXqzVjEefHlkOJEXiaA2sf/g5MHv/Zt5lWaasXwwn4lK1 MTZKjZFLkPtlZ+wTW44zWzuUu+UrqxNJwxRCkRseEU0hXTaJTwXHS0MFut170Msg2NLN 1VfHOWekGsetnWF2bgz1vX7aKthpZJkVHzQc80SWq7QVlVn8u3LpPVv3rvJ/vrMvyvXb KBKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733456305; x=1734061105; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=yapDheH9AE3cY7SG3Bmd2k0N02t4sOTFZafr3pCQcdA=; b=hIgbhrupYkMSdncRK0T83ng/7lpeu/kvGMgRY4iG4AuM5x6jxr/d3CL0EVfCT39jSc 6JSo0xd81CYPLTapIvC43KVBq2fdhSRzCJZAiVg+sR1OWFsbbtsAx+xB4cAzxnGRV9ZP 432JI+jq4y24iSDOJr5U7H/GUjNtnq/iFfx2+WPEVpZeqhLiNmSkHxMKOrx6CutBXMcA b+vKf9InA4FSojWeCHfyPHbzpsGBCNORsfBARVdbjww6EgUhxQ2qP0yu1mBfOC5P4382 RL5ThO221NI56gxUJgrDHdLk0Jo5VSs2Vyc9tP8yFIA9yxN45lpWp2enIBv8Lbhf4k1H /waA== X-Gm-Message-State: AOJu0YzdUpkrDtKF1dhywXu+5vMhzICM1uHu8LKoPccWCaBtYSZenRyL HKZ+9SQUITUlJ49oZgp/Xc6CiHKPDEPM0Xo7RSuk3XZpTJKEEEBohW+9y8mbQnqgiKnJVv6jKtC wmG1b0T2mwI/T6jwpbF1F1BGF3+uEd6ja X-Gm-Gg: ASbGncu9UAYrnvM4yNB762lHKYILZ1YwRP/s6BRpUhGzv2qcuq/2TdCGM3pCcYj64gO 7MFsMhfouF+RyBJKBVamuU+fKTVkexCDo X-Google-Smtp-Source: AGHT+IGQI6GbCsynPM0yGiikMf7jU8P/SoG7X6AmoqEeIMhH9odQ8N69Vr+pRRDiFtF60fHgIIhdGWBXRvYiKAiffYs= X-Received: by 2002:a17:90b:1a8e:b0:2ee:bbe0:98c6 with SMTP id 98e67ed59e1d1-2ef6965469cmr2266996a91.8.1733456304884; Thu, 05 Dec 2024 19:38:24 -0800 (PST) MIME-Version: 1.0 Date: Thu, 5 Dec 2024 22:38:13 -0500 Message-ID: To: rauc@pengutronix.de Content-Type: text/plain; charset="UTF-8" X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on metis.whiteo.stw.pengutronix.de X-Spam-Level: X-Spam-Status: No, score=-2.4 required=4.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.2 Subject: [RAUC] Is it possible to change the [system]compatible= string after it has already been set/flashed? X-BeenThere: rauc@pengutronix.de X-Mailman-Version: 2.1.29 Precedence: list List-Id: RAUC Project - Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Brian Hutchinson via RAUC Reply-To: Brian Hutchinson Sender: "RAUC" X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: rauc-bounces@pengutronix.de X-SA-Exim-Scanned: No (on metis.whiteo.stw.pengutronix.de); SAEximRunCond expanded to false Hi, Since it's common to produce boards with pre-programmed flash etc., is it possible to change the [system]compatible= string when hardware changes happen and the compatible string needs to be updated when it has already been set previously? I know that hooks could be used to key in on bundle version information to implement things like downgrade barriers etc., but it just feels more elegant to update the compatible string to describe hardware changes that are human readable than to keep up with a eye chart truth table of version number combinations to determine what is safe to downgrade, upgrade etc. I was thinking if maybe [system]variant-file was used in system.conf, then a pre-install hook could easily manipulate the compatible string, but not sure that would work. This almost feels like the intermediate update that's necessary with changing rauc versions ... but I searched the mail archives and couldn't find anyone wondering about this sort of thing so thought I'd ask Jan, Enrico & Co. their thoughts. Regards, Brian