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

[Alexander Smirnov <asmirnov@ilbers.de>]

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.


Moreover 'man 1 multistrap' states the same:
...
The combination of default release, explicit suite and apt preferences 
can quickly become complex and bugs can be very hard to identify.
...

So, from two options:

  - Rename custom kernel package
  - Prioritize apt

the first one looks more easy and robust.

> 
>>
>> For me this approach looks like a good way to have unexpected troubles
>> like the following:
>>
>> 1. You pick current glibc from upstream distro XYZ, let's say v1.0.
>> 2. Patch it and put glibc-v1.0-isar to isar-apt.
>> 3. Wait for some time until glibc is updated in upstream, let's say to
>> v1.1.
>> 4. Due to glibc-v1.0-isar is set to be preferred, it's going to be
>> installed. But glibc is the core library in distro, and lots of packages
>> in XYZ now require glibc-v1.1. So even if you will be able to generate
>> image, you can't guarantee it works correctly...
> 
> Well, sure, no one takes away the task from you of properly maintaining
> the recipes when upstream updates happen (and you pull them into your
> reproducible build).

If this is only about specific package[s], I'd suggest to propose this 
feature as an option to *overwrite* the specific package and do not do 
this by default for the whole isar-apt.

Alex