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

[Jan Kiszka <jan.kiszka@siemens.com>]

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 <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.

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.

> 
> 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.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux