Re: Multi repo support

[Alexander Smirnov <asmirnov@ilbers.de>]

On 02/01/2018 09:51 PM, Claudius Heine wrote:
> Hi,
> 
> On Thu, 2018-02-01 at 19:34 +0100, Henning Schild wrote:
>> Am Thu, 1 Feb 2018 16:16:58 +0100
>> schrieb "[ext] Henning Schild" <henning.schild@siemens.com>:
>>
>>> Am Thu, 1 Feb 2018 15:54:26 +0100
>>> schrieb "[ext] Claudius Heine" <claudius.heine.ext@siemens.com>:
>>>
>>>> Hi,
>>>>
>>>> I would like to start the discussion about how to best implement
>>>> muti repository support in isar.
>>>>
>>>> Does someone already has some ideas or even something in the
>>>> pipeline for this?
>>>>
>>>> If not then I do have an idea that was outlined together with
>>>> Jan:
>>>>
>>>> Adding and configuring apt repositories should be done via config
>>>> files. It should be possible to define own multiconfigs while
>>>> including multiconfigs from other layers. These configs then
>>>> append
>>>> filepaths to a global variable.
>>>>
>>>> Every file that is added this way contains 'sources.list'
>>>> compatible repository definitions. So one repo each line.
>>>>
>>>> For every line in those files a repository entry for
>>>> multistrap.conf
>>>> is created. Here we might need some more complex code to convert
>>>> such a apt repo tripel to the right format multistrap expects.
>>>> But
>>>> by using the 'sources.lists' format we would be independent of
>>>> multistrap and become more future proof.
>>
>> We will also need a way to tell apt the priorities of these repos.
>> Multistrap just adds them and apt-get installs packages according to
>> its default behavior.
>> That means that a package with the same name and version will get
>> picked from a "random" repo. Overlays will need to make sure to
>> always
>> have a greater version or we will need apt configuration.
>> https://wiki.debian.org/AptPreferences
>> The big question here is how/whether multistrap will handle apt
>> preference.
>>
>> Alex already ran into that when he wanted to modify "hello". Renaming
>> packages - like Alex suggested - is not the way to go. Because the
>> ones
>> we do overlay could be deps of packages we do not overlay.
> 

The version collision could be avoided by using epoch, and if I 
understand it correctly - this is the preferable way to assign apt priority.

https://www.debian.org/doc/debian-policy/#s-f-version

Regarding renaming 'hello' there was a bit different case, our 'hello' 
has nothing common with the upstream one, moreover I've already modified 
it to use 'libhello'. So this is not the case when we patch the upstream 
package. So I decided to rename it, to avoid confusion.

In case of patching the upstream package, we could just add epoch to 
version, so our package will be always in first prio.

Also I'm not sure that when there are 2 packages with the same names and 
versions available in source.list - is a good practice. In this case you 
have no way to easily check if your rootfs contains correct package, 
'dpkg -l' won't be enough.

Alex

> Thanks, yes that is a very good point.
> 
> I would prefer the apt preferences settings. Maybe handle it similar to
> how I proposed the multi-repo support. A global variable where apt
> preference file paths are appended.
> 
> If multistrap cannot support them with a reasonable complex conversion
> script then it might be time to say multistrap goodbye.
> 
> Claudius
>