From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6520199916203016192 X-Received: by 10.101.74.76 with SMTP id a12mr2372079pgu.97.1518453107890; Mon, 12 Feb 2018 08:31:47 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a17:902:8c92:: with SMTP id t18-v6ls5095396plo.10.gmail; Mon, 12 Feb 2018 08:31:47 -0800 (PST) X-Google-Smtp-Source: AH8x227j4nEoPThM7AmzE8NRPavItTJxhD3JknrloaJfX6bItrI5KO4fyuiZoKlgpH87Q2ba8SQl X-Received: by 2002:a17:902:221:: with SMTP id 30-v6mr85720plc.35.1518453107358; Mon, 12 Feb 2018 08:31:47 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518453107; cv=none; d=google.com; s=arc-20160816; b=WNcIgALQ97+mdQoVWoFent6Gie4dgBLoaTzoryPiofInX+3JrHBdFNOO8Tfa1pS+Wf F2J/7YZBELwlwLVPWL/YoBtewpyBghizqhupzwxItQwdgLBz1LUT1NV+umfp/qJP+p0M rdJiFdWRp0tGkKYJL+xg77+GJ4KVDNEwIk0Jm8zH28BJz6opcOlaCA3y31k+D54h4Wd/ Nl52nZgNM1VaUzYIEhwRg99yIuyehAFMmrEqN3FZrz9xcI1K4mvAAA/NOG3JHjTfyn6w 981+hlzaFnLU4WIjYxvX33wDTOclLX+rx9turX05y8oi4V3gwc9Zdr9g6U1yJFpqtgrP N0jw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:content-language:in-reply-to:mime-version :user-agent:date:message-id:from:references:to:subject :arc-authentication-results; bh=YTX58qeqTLuigmu6D8LPs/DgFjyUCOkkP5aklIjQ+Io=; b=z48McLDDYns/PEyfF9DGBPrWmYRketsetUR9GxWj3ffHxLED8nTXNstL47megGXs9E yYFBzpMqS+t84hU0P54uzbyMXaDicmQXXz1SoNMpguJ/pxMivsvVHOoQtSQX1srQSh5q +2CmO1UKtgS5gjkBvSrpfSdslzCDS8sxhWQA7NUAKs3mqTu20zmo3wPrwpYCwuDfJmCN 2aLndq4HmQBEAz7OGuuH9PIrf868xfX+aBAecYZ4dczTkujDr5Zz+CGSZW1CmOmJdsCy tOs5LI6Pvdr+VwUAoIN977ddKDwX7//YZDKr7lYrU3gMnTrUWtHCjHimBhXACEN2q4hS xcSA== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: best guess record for domain of asmirnov@ilbers.de designates 85.214.62.211 as permitted sender) smtp.mailfrom=asmirnov@ilbers.de Return-Path: Received: from aqmola.ilbers.de (aqmola.ilbers.de. [85.214.62.211]) by gmr-mx.google.com with ESMTPS id x22si401412pgv.3.2018.02.12.08.31.45 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Feb 2018 08:31:46 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of asmirnov@ilbers.de designates 85.214.62.211 as permitted sender) client-ip=85.214.62.211; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: best guess record for domain of asmirnov@ilbers.de designates 85.214.62.211 as permitted sender) smtp.mailfrom=asmirnov@ilbers.de Received: from [10.0.2.15] ([188.227.110.165]) (authenticated bits=0) by aqmola.ilbers.de (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id w1CGVd6c001481 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 12 Feb 2018 17:31:41 +0100 Subject: Re: [PATCH v4 2/8] Prioritize isar-apt repo over all others To: Jan Kiszka , isar-users References: <136df397-5fce-9f50-fd74-f35f038fbda2@siemens.com> <905dabd5-e9b9-9382-8c86-8e33d8559b21@siemens.com> <65f07e31-b2d7-4858-440e-f32f1a9b0832@siemens.com> From: Alexander Smirnov Message-ID: Date: Mon, 12 Feb 2018 19:31:34 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <65f07e31-b2d7-4858-440e-f32f1a9b0832@siemens.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-TUID: 0v1ght3BUubq On 02/12/2018 04:45 PM, Jan Kiszka wrote: > On 2018-02-12 14:09, Alexander Smirnov wrote: >> On 02/12/2018 01:27 PM, Jan Kiszka wrote: >>> On 2018-02-12 11:11, Jan Kiszka wrote: >>>> On 2018-02-12 11:08, Alexander Smirnov wrote: >>>>> On 02/12/2018 12:41 PM, Jan Kiszka wrote: >>>>>> On 2018-02-12 10:33, Alexander Smirnov wrote: >>>>>>> On 02/11/2018 06:25 PM, Jan Kiszka wrote: >>>>>>>> From: Jan Kiszka >>>>>>>> >>>>>>>> This ensures that we can override packages from upstream Debian or >>>>>>>> other >>>>>>>> external sources with our self-built versions. We achieve this >>>>>>>> for now >>>>>>>> by asking multistrap to drop a preferences file for the >>>>>>>> buildchroot so >>>>>>>> that dependency installations use the right priority. For the image >>>>>>>> build, this does not work because all packages are pull during the >>>>>>>> bootstrap. Therefore, we set aptdefaultrelease to isar to ensure >>>>>>>> that >>>>>>>> our repo gets the higher priority. >>>>>>>> >>>>>>> >>>>>>> I'm not sure that I completely understand this. What is the >>>>>>> use-case for >>>>>>> this? If you build your own copy of upstream package, this >>>>>>> prioritization could be resolved by specifying suffix to version. >>>>>> >>>>>> Simple example: custom kernel build of linux-cip >>>>>> >>>>>> This generates a package called linux-image-amd64 (for amd64 as >>>>>> target), >>>>>> and that may have a version < debian's kernel. Now, if we do not >>>>>> prioritize isar-apt over upstream, the upstream kernel is taken, even >>>>>> when you switched PREFERRED_PROVIDER (in fact, the build will break >>>>>> when >>>>>> that virtual package linux-cip is selected but can't be installed >>>>>> due to >>>>>> the version preference "newest"). >>>>> >>>>> Ok, but why you can't name you kernel 'linux-cip-image-amd64'? Having >>>>> the same name as with original Debian one could be confusing. >>>>> >>>> >>>> That is mandatory, in order to write packages that depend on THE kernel, >>>> instead of "my-custom-kernel-in-version-4.4.112". >>> >>> To make it clearer, just look at the example-module case: The recipe can >>> build both against the distro as well as all custom kernels, without >>> touching it. And that is a pattern not limited to kernel<->module >>> relationships. >> >> kernel<->module pair are built from the same source tree, so here no >> problem with ${PN}-${PV} substitution as dependency. Also I've parsed >> pure Debian packages, nobody depends from 'linux-image-*', so no >> correlation with upstream packages. > > No, they can be independent, just like in the example I submitted. It's > an external kernel module vs. some kernel. Please re-read. > > For Debian, this specific problem does not exist because Debian only > ships in-tree modules or those that are built on the target on > installation. But you will find the exact same pattern when browsing > external projects that come with modules. Ok, I see that you define KERNEL_ARCH variable in machine config and this variable is used to bind kernel<->module build process. Sometimes KERNEL_ARCH has to be changed according to your kernel configuration. It's not enough to change preferred_provider from "linux-distro" to "linux-cip" if you want to use LPAE for your ARM kernel. You also need to change KERNEL_ARCH from "armmp" to "armmp-lpae" to be correct. How you see the overall procedure to switch to custom kernel? Why KERNEL_ARCH can't be "cip-armmp" in this case? For example armbian uses branch names and machines to distinguish images: https://www.armbian.com/kernel/ - linux-image-dev-sun8i - linux-image-next-odroidc2 So if define KERNEL_ARCH as ${ORIGIN}-${MACHINE}, you never will get conflicts with the upstream. Also this doesn't affect modules building at all. > >> >> What are the other use-cases for this pattern? As I mentioned above with >> 'glibc' example, this is unclean approach, distro could become broken at >> anytime. This could become robust *only* after build reproducibility >> integration, when you cache the upstream content. But with build-rep you >> could manually manage the content of the cache, so prioritization is not >> needed, you could just drop duplications from the cache. > > Every lib-dependency is another pattern for the special kernel/module > case: Every distro package that come with a dependencies that you want > to replace with a custom build AND you have good reason to downgrade > that package, then you want your own packages to have higher prior. > That's why this hard-coding is the right thing to do, in general: If you > are building a package that competes with upstream, there must be a > reason... > >> >> In general having packages with the same name in 'source.list' and >> overriding version policies in apt looks very dangerous for me. >> >> If the current series requires prioritization for kernel only, it would >> be nice to specify only this package in apt preferences. > > See above, the kernel is just the first case. There will be more, I'm > absolutely sure. I've asked especially about these cases. :-( At the moment there is only kernel case, which could be solved without this prioritization. Alex