From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6647132102307348480 X-Received: by 2002:a2e:5d84:: with SMTP id v4-v6mr673001lje.4.1547656045762; Wed, 16 Jan 2019 08:27:25 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a19:3fc4:: with SMTP id m187ls681113lfa.1.gmail; Wed, 16 Jan 2019 08:27:25 -0800 (PST) X-Google-Smtp-Source: ALg8bN49vpXXge19s6zXyG5seOoLGhk6Li55AJgkZwIAFAWAUCy7k/A26t9ZEai6RblkddRRAY62 X-Received: by 2002:a19:740a:: with SMTP id v10mr698076lfe.16.1547656045315; Wed, 16 Jan 2019 08:27:25 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1547656045; cv=none; d=google.com; s=arc-20160816; b=Bqn5t/RWqgQhka7Iinsx5kSJuvI+IoP9M9pysr11scZkBhEiVSzxfOdT6ue04Kj1AY 1bAOCS1cTWdfjBMxbNvWmKTQpCz2TCZlZoTYqvWgLVFodCKVotpl+Vs5C75+Imr4l78Z oOOUMUXRsAed01+IvAtfAXq5GbRfGOcM/gy2cOYEBnqRDZrNpte465msUiITDn5JDZdc flhIEn59d1DdOPxMTUJmNVa3n1lRfyHNjQQyiMkFAXDmYtIorr9BoI4BnmpvEm3TNJyk O4Y/cUlledOH7sOQUoh11mP2UNGZpDzxX02dWAoHbchkYJ8SVshtiyL42yKEaz4E0opY +vNg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:message-id:subject:to:from :date; bh=wT/f28guslqfMbbA4bB37CT3MGf82IavvB/ONfGjZac=; b=J23OMrRjT97GRrzUK5NJ3ibk34fz5p0GJWzeDDpK0EE3aEZYVA7vfcpFZcvnbE1ESa u/seIi/N77q7z3FSltiTKHYhoTP7ORDDXjOzl/CeIPuBX2lBns0KpntYc0x1oK+w9q9X SOVr9TXEn9FP/NGIO13Ywf3g16eQGq92iDQhi4Ee0gx0pNUCcMX9na+wnyevIRR9YZ73 ufHuhGTSxY7QmLDu01LhYaUHGuHd6gG/MwxCcDi764m/TRbwcTVeq9MSMEcvt5mObG0z oYrwEErNI/C8SgaSM8SDfDNgrCJyZ/97vyYZn11/VXkoRnOsHsgkv+LezbdfjyzOXW3Z ZU5Q== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 194.138.37.40 as permitted sender) smtp.mailfrom=henning.schild@siemens.com Return-Path: Received: from gecko.sbs.de (gecko.sbs.de. [194.138.37.40]) by gmr-mx.google.com with ESMTPS id t5-v6si305435lje.3.2019.01.16.08.27.25 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 Jan 2019 08:27:25 -0800 (PST) Received-SPF: pass (google.com: domain of henning.schild@siemens.com designates 194.138.37.40 as permitted sender) client-ip=194.138.37.40; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 194.138.37.40 as permitted sender) smtp.mailfrom=henning.schild@siemens.com Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by gecko.sbs.de (8.15.2/8.15.2) with ESMTPS id x0GGROgd004194 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Wed, 16 Jan 2019 17:27:24 +0100 Received: from md1za8fc.ad001.siemens.net ([139.25.69.250]) by mail1.sbs.de (8.15.2/8.15.2) with ESMTP id x0GGROon022621; Wed, 16 Jan 2019 17:27:24 +0100 Date: Wed, 16 Jan 2019 17:27:24 +0100 From: Henning Schild To: isar-users , "Kiszka, Jan (CT RDA IOT SES-DE)" Subject: custom-kernel downgrade and linux-libc-dev Message-ID: <20190116172724.7811cfba@md1za8fc.ad001.siemens.net> X-Mailer: Claws Mail 3.15.0-dirty (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-TUID: i3uPCKv0Qjyc Hi, our custom kernel builds always generate a linux-libc-dev package matching the kernel kernel version. So for a cip you would get linux-libc-dev-4.4.xx. Prebuild debian packages from upstream depend on a linux-libc-dev >= . I.e. you want build-essential in stretch, you will end up with a "Depends: linux-libc-dev (>= 4.9.65-3)" somewhere in your deps chain. But if you are building a custom kernel lower than the expected version you will end up with a smaller linux-libc-dev in the isar repo. And the strong pinning will leave apt no choice but to give up and trying to resolve the problem. So if you want to include i.e build-essential into an image with a kernel downgrade, you will not be able to build that image. That issue is especially problematic since it will creap into the buildchroot after the package was deployed by the first kernel build. And you will end up with a setup where partial rebuilds involving buildchroot changes will not work anymore. In the layer i discovered this problem in i now remove the linux-libc-dev package in a do_deploy_deb_prepend. That seems to be a working hack for the downgrade case, but might not be the best idea for an upgrade case. But my current suggestion would be to ignore the whole issue of kernel header compatibilty and never deploy the linux-libc-dev package from custom kernel builds. Thoughts? Henning