From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6517599416265736192 X-Received: by 10.80.242.130 with SMTP id f2mr13833330edm.5.1517521963543; Thu, 01 Feb 2018 13:52:43 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 10.80.170.50 with SMTP id o47ls405104edc.3.gmail; Thu, 01 Feb 2018 13:52:43 -0800 (PST) X-Google-Smtp-Source: AH8x226a8kSUF9LcZ7nEzbdvOpNfVy/m6M7ZaUgve2UaHqVwxzaTNkKGcoR9vISnD+8Zf0He34HJ X-Received: by 10.80.141.204 with SMTP id s12mr3331256edh.10.1517521963040; Thu, 01 Feb 2018 13:52:43 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1517521963; cv=none; d=google.com; s=arc-20160816; b=KXT/tGqyCV7Zvu6pUBWClbPbU+jFt3pzO3EpEToyqh2Mc6O+PHYcoVmoZv5hGglfn7 RUGFNdyBzJ96Gh3tDL8CjfjGOsYaeUnVqIZ56uJB4w/PcGBXd+0NPuv3SPtJjHfI90m3 lAdDy/xcohSV4ZiodlLhTvkNoNMrfOWldAqJrOqWsvbfT+dI3HVf8eHtNUFbTNqdOo/8 8K2wQO13PzLI4ZGHXDsgrPaoP9hmtu6ob0WBXTpuE+U5a17orTcDwh0RZqzi7LSfOfqK elI0LoQ6huIgEz5/03HLKNhp18Q6u+NgIixNYqADN6t+8KqRy1BzDyyKl6v/jBFGY9YS ghrQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:subject:user-agent :references:in-reply-to:message-id:date:cc:to:from :arc-authentication-results; bh=X3xv/4IhutwEwpLBf2g66jXEkTgjKtAAQGz0z0j8yPw=; b=NMqRqnWR2AtsQ1Y5fbFc80uWvryaNqfHHNXOUPuae7dKu+bXi05WHIG+mVUzz2yC4o ZFbHUaf9MZQIe/Yquceu4J4YGHmfZB+ln75+f5nz0lU/TYYxOih/icMJiH9cEAfSLVTC YSjChfQjTHkqIlmbFdrCvvNWRwUxEXTMPeXNq3Fo9TS5QYXD50bUVlbJA7PvwGacgK5Q LhUTY1xQpHHwACMJu1TWwviXY/t2hu+zrJAgEV8izM8feUesAgeM0Ek8J7KW+XH7I2Fd lqZJ0VUcRQROVfWm7OstZI6oU75T1wxJo4Sf2Acyc4lB2uJlHbtEGQmUhNbvKF0hKpA6 vrlw== 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 v28si57657edd.3.2018.02.01.13.52.42 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Feb 2018 13:52:42 -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 [192.168.1.235] ([188.227.110.165]) (authenticated bits=0) by aqmola.ilbers.de (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id w11LqdfP013103; Thu, 1 Feb 2018 22:52:40 +0100 From: Alexander Smirnov To: Claudius Heine , Henning Schild , "[ext] Claudius Heine" CC: "isar-users" Date: Fri, 02 Feb 2018 00:52:50 +0300 Message-ID: <161535ba350.27ac.034a6b0541ed39b7fb4e17f4ac219eaa@ilbers.de> In-Reply-To: <1517519259.2646.39.camel@denx.de> References: <7714f0e1-aaca-add2-eabc-738d4043c21c@siemens.com> <20180201161658.6b0af973@mmd1pvb1c.ad001.siemens.net> <20180201193458.24b6ac3f@mmd1pvb1c.ad001.siemens.net> <1517511108.2646.24.camel@denx.de> <1517519259.2646.39.camel@denx.de> User-Agent: AquaMail/1.10.0-403 (build: 101000001) Subject: Re: Multi repo support MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8" Content-Transfer-Encoding: 8bit X-TUID: FI/DQ39qKc1g Hi! Claudius Heine 2 февраля 2018 г. 0:07:49 написал: > Hi Alex, > > On Thu, 2018-02-01 at 23:47 +0300, Alexander Smirnov wrote: >> >> 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" : >> > > >> > > > Am Thu, 1 Feb 2018 15:54:26 +0100 >> > > > schrieb "[ext] Claudius Heine" >> > > > : >> > > > >> > > > > 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 > > Where did you get that epoch is the preferable way to assign apt > priority? Not the apt, just specific package. Hmm, I'm a bit incorrectly called my pov. :-) I see epoch as an easy way to patch existing package from upstream. You don't care about upstream one's version even if it goes forward, until your epoch is higher - your package will be installed. Of course it doesn't mean that upstream epoch couldn't be changed too, but this happens quite rare. > > From you link: > > epoch > This is a single (generally small) unsigned integer. It may be > omitted, in which case zero is assumed. If it is omitted then the > upstream_version may not contain any colons. > It is provided to allow mistakes in the version numbers of > older versions of a package, and also a package’s previous version > numbering schemes, to be left behind. > > I see epoch just as a possibility to fix mistakes or if upstream > changed their versioning scheme, not use it use it generally for > specifying package priorities. Using it that way sound more like a hack > to me. Because what happens if debian raises the epoch of a package? > Then you would have to raise yours again? Sounds like playing poker. Could you please describe the case when you have two repositories which contain package with the same name-version but different content? Alex > > Telling apt to prefer packages with specific versions or from specific > repositories via apt-preferences sounds more like the right tool for > the job. > > Cheers, > Claudius > >> >> 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 >> > > -- > DENX Software Engineering GmbH, Managing Director: Wolfgang Denk > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > Phone: (+49)-8142-66989-54 Fax: (+49)-8142-66989-80 Email: ch@denx.de > > PGP key: 6FF2 E59F 00C6 BC28 31D8 64C1 1173 CB19 9808 B153 > Keyserver: hkp://pool.sks-keyservers.net