From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <pve-devel-bounces@lists.proxmox.com>
Received: from firstgate.proxmox.com (firstgate.proxmox.com [IPv6:2a01:7e0:0:424::9])
	by lore.proxmox.com (Postfix) with ESMTPS id 633981FF13E
	for <inbox@lore.proxmox.com>; Fri, 06 Feb 2026 15:30:10 +0100 (CET)
Received: from firstgate.proxmox.com (localhost [127.0.0.1])
	by firstgate.proxmox.com (Proxmox) with ESMTP id D26715E71;
	Fri,  6 Feb 2026 15:30:41 +0100 (CET)
Message-ID: <b0a7c747-f48c-43c7-89ca-73f9d7dc5da6@proxmox.com>
Date: Fri, 6 Feb 2026 15:30:05 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird Beta
Subject: Re: [PATCH container v2 3/4] setup: add no-op detect_architecture for
 unmanaged CTs
To: Fiona Ebner <f.ebner@proxmox.com>, Daniel Kral <d.kral@proxmox.com>,
 pve-devel@lists.proxmox.com
References: <20260206124513.310674-1-d.kral@proxmox.com>
 <20260206124513.310674-4-d.kral@proxmox.com>
 <5a6b230c-0de8-4e99-959d-55c4649f0d85@proxmox.com>
Content-Language: en-US
From: Thomas Lamprecht <t.lamprecht@proxmox.com>
In-Reply-To: <5a6b230c-0de8-4e99-959d-55c4649f0d85@proxmox.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2
X-Bm-Transport-Timestamp: 1770388126804
X-SPAM-LEVEL: Spam detection results:  0
	AWL                    -0.022 Adjusted score from AWL reputation of From:
 address
	BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
	DMARC_MISSING             0.1 Missing DMARC policy
	KAM_DMARC_STATUS         0.01 Test Rule for DKIM or SPF Failure with Strict
 Alignment
	RCVD_IN_VALIDITY_CERTIFIED_BLOCKED  0.001 ADMINISTRATOR NOTICE: The query to
 Validity was blocked.  See
 https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more
 information.
	RCVD_IN_VALIDITY_RPBL_BLOCKED  0.001 ADMINISTRATOR NOTICE: The query to
 Validity was blocked.  See
 https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more
 information.
	RCVD_IN_VALIDITY_SAFE_BLOCKED  0.001 ADMINISTRATOR NOTICE: The query to
 Validity was blocked.  See
 https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more
 information.
	SPF_HELO_NONE           0.001 SPF: HELO does not publish an SPF Record
	SPF_PASS               -0.001 SPF: sender matches SPF record
Message-ID-Hash: HWWHOMQV36QCD3SKT7HPFUFTXNIVCNQ7
X-Message-ID-Hash: HWWHOMQV36QCD3SKT7HPFUFTXNIVCNQ7
X-MailFrom: t.lamprecht@proxmox.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop;
 banned-address; emergency; member-moderation; nonmember-moderation;
 administrivia; implicit-dest; max-recipients; max-size; news-moderation;
 no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.10
Precedence: list
List-Id: Proxmox VE development discussion <pve-devel.lists.proxmox.com>
List-Help: <mailto:pve-devel-request@lists.proxmox.com?subject=help>
List-Owner: <mailto:pve-devel-owner@lists.proxmox.com>
List-Post: <mailto:pve-devel@lists.proxmox.com>
List-Subscribe: <mailto:pve-devel-join@lists.proxmox.com>
List-Unsubscribe: <mailto:pve-devel-leave@lists.proxmox.com>

Am 06.02.26 um 14:08 schrieb Fiona Ebner:
>> +sub detect_architecture {
>> +    my ($self) = @_;
>> +    return;
> Thinking through it again, should we rather just die here instead of
> returning undef? It seems to me that the contract for the method is
> currently "either return the detected architecture or die". Then patch

That description of the contract is not correct, for normal os types
it fails if the arch could not be detected, for unmanaged this should
not be the case, as we never can detect it there by design, and returning
undef is more correct as of now.

> 4/4 would not be needed. Your new implementation adds a "or return
> undef" to the contract making it more complicated.