Re: [PATCH v4 2/8] Prioritize isar-apt repo over all others

[Alexander Smirnov <asmirnov@ilbers.de>]

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 <jan.kiszka@siemens.com>
>>>>>>
>>>>>> 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.

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.

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.

Alex