From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6517599416265736192 X-Received: by 10.28.63.65 with SMTP id m62mr3471511wma.18.1517553663734; Thu, 01 Feb 2018 22:41:03 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 10.223.144.41 with SMTP id h38ls364945wrh.11.gmail; Thu, 01 Feb 2018 22:41:03 -0800 (PST) X-Google-Smtp-Source: AH8x227xD+/VHhJmBuqhxIAPbhZjtW/CxSJwWiFejZ32u0bVRG479ynQQSlh2aPJuXYOBu3F+1+P X-Received: by 10.28.153.194 with SMTP id b185mr4204681wme.9.1517553663195; Thu, 01 Feb 2018 22:41:03 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1517553663; cv=none; d=google.com; s=arc-20160816; b=SZLIeptrqzcsRE0gvoVTVGSEGyb1UwOH+7RLYXMFt/URIYoBY3PbIV/7S3RE3ukRI2 L/wtipZS9G/Rd5V21gy4ZOgjxrwgd3AGXmRd8w4bimud5UbradBoKteXFHNO5amhn3qC YIdoTjy7KRRwPU2R9JyyspzRsyEsqT/KNroqVzrf/W2I2McnbEUexusqrgPi2zN6cXX3 OAjAefEn4zkq/oS/9MESLW8ua8GinzgNIFsfxpH+PxezGgjg+9JNmXog/plYGjD8hELS ygiYNIDplInwjS9WBdhn2Y6s9Eo+a2Ud1H+HhbD93Z8PK73li0bag2DDEn74/sjyXgTh v6vw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=mime-version:references:in-reply-to:date:cc:to:from:subject :message-id:arc-authentication-results; bh=sIHrs5FWEqdPtYmz8SFUzVouS2wNl0lyIX60anzuPVA=; b=dMHOH7F3rsRAUb4vVR4WLucURvJzRrXJ3baCXbpbS2krtt8gER6YxKYoWls3Evyc4T 6lDWN0amqaIr+DaOxy+efcK5wtiIeZKr8cJJcOMW2695O7h5zvGSdF0GNtLBs/Fvn2/O 701ZtYoX+OHjTXHHGg5xx9pPy0tWP/II9xcM8/YssfD4lsgUc+Wq/Ofk5dcsDwC7Qzav b0e/LrePkxaeWFgbr+ucMiHNJzEED7ewWeDBhxgOuasLNMTxM9RTR9idkUxiTZJ0jdOg 2wy+Jgiv/wAL1igBB+0YFDML2LwKsynyGxUi0scVZY6WdNzlwbI9z7/f8ctKcs8mnraQ /kWw== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=neutral (google.com: 212.18.0.9 is neither permitted nor denied by best guess record for domain of ch@denx.de) smtp.mailfrom=ch@denx.de Return-Path: Received: from mail-out.m-online.net (mail-out.m-online.net. [212.18.0.9]) by gmr-mx.google.com with ESMTPS id i75si38532wmg.1.2018.02.01.22.41.03 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Feb 2018 22:41:03 -0800 (PST) Received-SPF: neutral (google.com: 212.18.0.9 is neither permitted nor denied by best guess record for domain of ch@denx.de) client-ip=212.18.0.9; Authentication-Results: gmr-mx.google.com; spf=neutral (google.com: 212.18.0.9 is neither permitted nor denied by best guess record for domain of ch@denx.de) smtp.mailfrom=ch@denx.de Received: from frontend01.mail.m-online.net (unknown [192.168.8.182]) by mail-out.m-online.net (Postfix) with ESMTP id 3zXnSG68Sxz1qtH8; Fri, 2 Feb 2018 07:41:02 +0100 (CET) Received: from localhost (dynscan1.mnet-online.de [192.168.6.70]) by mail.m-online.net (Postfix) with ESMTP id 3zXnSG5j8Bz1qrDH; Fri, 2 Feb 2018 07:41:02 +0100 (CET) X-Virus-Scanned: amavisd-new at mnet-online.de Received: from mail.mnet-online.de ([192.168.8.182]) by localhost (dynscan1.mail.m-online.net [192.168.6.70]) (amavisd-new, port 10024) with ESMTP id W6xNfsRW3dAz; Fri, 2 Feb 2018 07:41:01 +0100 (CET) X-Auth-Info: 0b4bDDgyoez5D8Tl6dMzDJK3BTSzcSM6uZ3LM3Vj46c= Received: from Orrorin.lan (ipservice-092-217-126-008.092.217.pools.vodafone-ip.de [92.217.126.8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.mnet-online.de (Postfix) with ESMTPSA; Fri, 2 Feb 2018 07:41:01 +0100 (CET) Message-ID: <1517553656.2646.52.camel@denx.de> Subject: Re: Multi repo support From: Claudius Heine To: Alexander Smirnov , Henning Schild , "[ext] Claudius Heine" Cc: isar-users Date: Fri, 02 Feb 2018 07:40:56 +0100 In-Reply-To: <161535ba350.27ac.034a6b0541ed39b7fb4e17f4ac219eaa@ilbers.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> <161535ba350.27ac.034a6b0541ed39b7fb4e17f4ac219eaa@ilbers.de> Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-n92h/8+MgAHzQ6SnTlW9" X-Mailer: Evolution 3.26.4 Mime-Version: 1.0 X-TUID: q6OLj+UGmafE --=-n92h/8+MgAHzQ6SnTlW9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, On Fri, 2018-02-02 at 00:52 +0300, Alexander Smirnov wrote: > Hi! >=20 > Claudius Heine 2 =D1=84=D0=B5=D0=B2=D1=80=D0=B0=D0=BB=D1=8F = 2018 =D0=B3. 0:07:49 =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB: >=20 > > Hi Alex, > >=20 > > On Thu, 2018-02-01 at 23:47 +0300, Alexander Smirnov wrote: > > >=20 > > > On 02/01/2018 09:51 PM, Claudius Heine wrote: > > > > Hi, > > > >=20 > > > > 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" : > > > > >=20 > > > > > > Am Thu, 1 Feb 2018 15:54:26 +0100 > > > > > > schrieb "[ext] Claudius Heine" > > > > > com> > > > > > > : > > > > > >=20 > > > > > > > Hi, > > > > > > >=20 > > > > > > > I would like to start the discussion about how to best > > > > > > > implement > > > > > > > muti repository support in isar. > > > > > > >=20 > > > > > > > Does someone already has some ideas or even something in > > > > > > > the > > > > > > > pipeline for this? > > > > > > >=20 > > > > > > > If not then I do have an idea that was outlined together > > > > > > > with > > > > > > > Jan: > > > > > > >=20 > > > > > > > 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. > > > > > > >=20 > > > > > > > Every file that is added this way contains 'sources.list' > > > > > > > compatible repository definitions. So one repo each line. > > > > > > >=20 > > > > > > > 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. > > > > >=20 > > > > > 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. > > > > >=20 > > > > > 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. > > >=20 > > > The version collision could be avoided by using epoch, and if I > > > understand it correctly - this is the preferable way to assign > > > apt > > > priority. > > >=20 > > > https://www.debian.org/doc/debian-policy/#s-f-version > >=20 > > Where did you get that epoch is the preferable way to assign apt > > priority? >=20 > Not the apt, just specific package. Hmm, I'm a bit incorrectly called > my=20 > pov. :-) I see epoch as an easy way to patch existing package from=20 > upstream. You don't care about upstream one's version even if it > goes=20 > forward, until your epoch is higher - your package will be installed. > Of=20 > course it doesn't mean that upstream epoch couldn't be changed too, > but=20 > this happens quite rare. >=20 > >=20 > > From you link: > >=20 > > 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=E2=80=99s previous vers= ion > > numbering schemes, to be left behind. > >=20 > > 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. >=20 > Could you please describe the case when you have two repositories > which=20 > contain package with the same name-version but different content? With apt-preferences we could prefer every package from our own repo with the same name AFAIK, but this would make the original package no longer install-able beside that. And that is a limitation of debian/dpkg and we can do nothing about it in isar. This problem it not ours to solve. Ideally debian would introduce package namespaces or similar. But that is completely out of isars scope. On our side we could only try some hacks to avoid name collision, but I would rather spend time solving other problems in isar than that, since just choosing a different name is pretty easy. Multi-repo or reproducible builds are much more important issues than trying to play cat and mouse with package names. Cheers, Claudius >=20 > Alex >=20 > >=20 > > Telling apt to prefer packages with specific versions or from > > specific > > repositories via apt-preferences sounds more like the right tool > > for > > the job. > >=20 > > Cheers, > > Claudius > >=20 > > >=20 > > > 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. > > >=20 > > > In case of patching the upstream package, we could just add epoch > > > to > > > version, so our package will be always in first prio. > > >=20 > > > 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. > > >=20 > > > Alex > > >=20 > > > > Thanks, yes that is a very good point. > > > >=20 > > > > 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. > > > >=20 > > > > If multistrap cannot support them with a reasonable complex > > > > conversion > > > > script then it might be time to say multistrap goodbye. > > > >=20 > > > > Claudius > > > >=20 > >=20 > > -- > > 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 > >=20 > > PGP key: 6FF2 E59F 00C6 BC28 31D8 64C1 1173 CB19 9808 > > B153 > > Keyserver: hkp://pool.sks- > > keyservers.net >=20 >=20 --=20 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 --=-n92h/8+MgAHzQ6SnTlW9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEb/LlnwDGvCgx2GTBEXPLGZgIsVMFAlp0B/gACgkQEXPLGZgI sVMJpRAAscP1j1Oyt2eRG603B+1VmS1mLXb5x5zp0ZX6Gt20jjsf2L4nB95BtLtm G0s/I3Iqo/zKGjdDA421TZw/TieVRbGSghoj/4o4CK16A0LKgkaslbGVyIgjO9kx 66Od+6Sylai1qV5X8jnlOcl/pTIQ8H7zJBkcDc4+K42iG2VxuKlNfGHz+gOnNvue W/VyxKcIvulXXv/wncbKLqKTGi2AgZzqJcjJvTsUAMnrTmy81aJQpMwvpW9aUFO5 vr46Ew7PZ5llJQDp6c9Rm+UejVfTBLfpVgZG4qNtwxEhIIzijnEpaJQNzKBLDll5 9RxO39dyO+kGczPsMK854wLU8AfLhZsFqInbVu4KoOTSGswR5YS7QLit/aXiPJBE R2tp7Q2bDAK0RG+dHq4wsxJaBm/H0FfGymILc6ukkCQ7BdjHQfJv1VamAQ5Iflmi KFJl1st42SfoTsFBOFRXDRRIGhWNltT7aLDXODfxssHLqYJd+JcGduVLIPPWwfH8 0m8IHzY19QV0d3zT11xB5Sgm+LjMoxvEQrw/via/rDJEGEFzC+Y1qgvb+ThkVHU3 LlYtynxTmoJX50LENVvhqcgAMMsqOmrX1NjNTNc6X/rlFkDGreh1HvlOq2pFvbHP R3wmsfVsKKcwfImovZe1KHhBKAI3gL+3TrJeZLl+AauS7G1+pmI= =yNmt -----END PGP SIGNATURE----- --=-n92h/8+MgAHzQ6SnTlW9--