Debian Bug report logs - #954138
Should not download indexes for architectures that are not enabled

version graph

Package: apt; Maintainer for apt is APT Development Team <[email protected]>; Source for apt is src:apt (PTS, buildd, popcon).

Reported by: Wouter Verhelst <[email protected]>

Date: Tue, 17 Mar 2020 11:03:01 UTC

Severity: wishlist

Found in version apt/1.8.2

Blocking fix for 947244: shouldn't include Architectures in sources file by default

Full log

đź”— View this message in rfc822 format

X-Loop: [email protected]
Subject: Bug#954138: Should not download indexes for architectures that are not enabled
Reply-To: Wouter Verhelst <[email protected]>, [email protected]
Resent-From: Wouter Verhelst <[email protected]>
Resent-To: [email protected]
Resent-CC: APT Development Team <[email protected]>
X-Loop: [email protected]
Resent-Date: Wed, 18 Mar 2020 10:24:03 +0000
Resent-Message-ID: <[email protected]>
Resent-Sender: [email protected]
X-Debian-PR-Message: followup 954138
X-Debian-PR-Package: apt
X-Debian-PR-Keywords: 
References: <[email protected]> <20200317153958.42a6gqkavwavvajl@crossbow> <[email protected]>
X-Debian-PR-Source: apt
Received: via spool by [email protected] id=B954138.158452692427671
          (code B ref 954138); Wed, 18 Mar 2020 10:24:03 +0000
Received: (at 954138) by bugs.debian.org; 18 Mar 2020 10:22:04 +0000
X-Spam-Checker-Version: SpamAssassin 3.4.2-bugs.debian.org_2005_01_02
	(2018-09-13) on buxtehude.debian.org
X-Spam-Level: 
X-Spam-Status: No, score=-12.1 required=4.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,HAS_BUG_NUMBER,SPF_HELO_NONE,
	SPF_PASS,TXREP autolearn=ham autolearn_force=no
	version=3.4.2-bugs.debian.org_2005_01_02
X-Spam-Bayes: score:0.0000 Tokens: new, 7; hammy, 150; neutral, 96; spammy, 0.
	spammytokens: hammytokens:0.000-+--H*u:1.10.1, 0.000-+--H*UA:1.10.1,
	0.000-+--H*u:2018-07-13, 0.000-+--H*UA:2018-07-13,
	0.000-+--kalnischkies
Received: from latin.grep.be ([2a01:4f8:140:52e5::2]:44842)
	by buxtehude.debian.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.92)
	(envelope-from <[email protected]>)
	id 1jEVpr-0007BQ-9C
	for [email protected]; Wed, 18 Mar 2020 10:22:04 +0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=grep.be;
	s=2017.latin; h=In-Reply-To:Content-Transfer-Encoding:Content-Type:
	MIME-Version:References:Message-ID:Subject:To:From:Date:Sender:Reply-To:Cc:
	Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
	Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
	List-Subscribe:List-Post:List-Owner:List-Archive;
	bh=UQlVUMDfF2jH1V+Pqxjaq59wtVuquKd5ZWpOcgJx1QY=; b=mqa++t7eN9KNPKLqiSRiETpx7b
	JxAkD9IfmN8G5yj1slGfUSi3BZY1HPJVjj6XYvkagPmsa9JRTbZqyPlNdjSBBdVlmWhFZRfoLuALJ
	qsDvWo5L5uJhaVate+e4qEZCnVeoGJCK09i03v49GL6GGKsmtDeAR68OWiM8Fi1DVjqGZMV3x6II6
	lXgIl+EB7y+Yp39xQAhgRxxBwqN5u716VhtHALbhfEx2GOa7ofhStnyD17aRD0rNUg8YQM50R/++a
	t/AH+p19cdhxeuylEu93zsvTJFYuCPExljb/lthsUTUSUEhBIwhtUjt+krrHu8G33EBgqglcRGe2o
	rRxzT13g==;
Received: from wouter by latin.grep.be with local (Exim 4.92)
	(envelope-from <[email protected]>)
	id 1jEVpl-0000NE-4i; Wed, 18 Mar 2020 11:21:57 +0100
Date: Wed, 18 Mar 2020 11:21:57 +0100
From: Wouter Verhelst <[email protected]>
To: David Kalnischkies <[email protected]>, [email protected]
Message-ID: <[email protected]>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20200317153958.42a6gqkavwavvajl@crossbow>
X-Speed: Gates' Law: Every 18 months, the speed of software halves.
User-Agent: Mutt/1.10.1 (2018-07-13)

On Tue, Mar 17, 2020 at 04:39:58PM +0100, David Kalnischkies wrote:
> It is possible that I completely misunderstood you though as I basically
> ignored your first example (and bugtitle) as it makes no sense to me and

Yes, sorry; I guess my mind got a better handle on what I was trying to
say as I was writing the message, and then forgot to update the earlier
messages.

> focused on the later examples… Why should someone configure a list of
> architectures in sources.list they do not want to be downloaded? That is
> like the freaking point of configuring the list in sources.list compared
> to just letting apt decide which architectures to download (based on
> what dpkg could process by default).

The problem is that apt will produce warning messages if the list of
architecture indexes it tries to download from a repository is not a
strict subset of the list of available architectures at that repository.

If I say "dpkg --add-architecture riscv64", then apt will try to
download riscv64 indexes from *all* my configured repositories,
including those that do not carry riscv64, and produce a warning message
for those that do not carry it. The only way to stop apt from issuing
those warnings (that I can see) is to add explicit configuration for
those repositories to list the architectures that it does support.

I try to do that with extrepo[1], as I think it is bad form to write
configuration files that will produce warning messages. However, the
result is now that I create configuration files which may say things
like "Architectures: i386 amd64 ppc64el" even on systems which do not
have one or more of those architectures enabled as foreign
architectures. While this will not produce warning messages, it does
result in a waste of bandwidth.

I guess what I want is for a way to avoid the warning messages? "Yes,
apt, these architectures are not expected to be there, leave that as is
now, kthxbye".

[1] https://packages.debian.org/extrepo

-- 
<Lo-lan-do> Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22

Send a report that this bug log contains spam.

Debian bug tracking system administrator <[email protected]>. Last modified: Tue May 13 11:40:49 2025; Machine Name: bembo

Debian Bug tracking system

Debbugs is free software and licensed under the terms of the GNU General Public License version 2. The current version can be obtained from https://bugs.debian.org/debbugs-source/.

Copyright © 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson, 2005-2017 Don Armstrong, and many other contributors.