From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6522397978051739648 X-Received: by 10.223.184.60 with SMTP id h57mr542226wrf.0.1518700628297; Thu, 15 Feb 2018 05:17:08 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 10.223.136.117 with SMTP id e50ls971581wre.3.gmail; Thu, 15 Feb 2018 05:17:07 -0800 (PST) X-Google-Smtp-Source: AH8x224UmTXH52vri/j1j+DwZ9x3yE1qlvrVmiIsvifpMAfkFXkvWkQ2dkycZjbyvx12NHiea+ty X-Received: by 10.223.186.201 with SMTP id w9mr900057wrg.14.1518700627802; Thu, 15 Feb 2018 05:17:07 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518700627; cv=none; d=google.com; s=arc-20160816; b=IxnVWdwyfRU16MzFO5pz3u76tljZI0hcgFwCJnP2HDCaH6cztVWpDuqsmT6K9ZB66R /lgorxy5xU5jH9n1pUCkS6QgeUYD1i+a1o9N3mlnLTpeApzrObOuCeUeOoglBD+Dxl+v AGTsAkE+YI58ShodIkpNa2qYbWpmvwJD0QPHKlNrvKDTv6NWYGYlZv8baEaIapT5DlHu veX+KvHnbvP0uBX068Tn/g1Gx/pXBSW6rqgdcLDGw0IQDf6qC+qceBt9jPMHVTXHOg4n bnPRsOPliAxwocqVyROqo84cAngMY41cL1F8GrXCFs2q1aDWqEPnTckXq9DHZRkJGYra zgLA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:content-language:in-reply-to:mime-version :user-agent:date:message-id:from:references:to:subject :arc-authentication-results; bh=TMT0/67gnJY45oKeOi4dI0XfDuSAI93e8GPyoazCSYU=; b=Xj9QJKOi+zR8EjLDvu5E0vLijPKXms8lvXtWI82a1bbFxll7dYSAmsWbrhIxUzSUhp pajSepv5UJaZcCGLvBM8nnfc9cICdpOebi5PBKqDQEbhcd89AZXSZ9YNgbUfVLGSR+mO QwsVXIeUQ+M67ceYjL266xtC5lfNyphoXQzBD0V8oZr2/YeP/LTgdayKtxp++uOGwLxa XL6QSOOKJt1ATPx0rYByTb+oNQVj5VexmlFBgN0bWkut0HvocZftLO5Fa+LNfcw/7iAC u/WxaEzxf0EJVLAxBqwvNN8u+CLlfABKkFsaqWHLhb4M1z6LB6b5gCE3UCMp7Z0Lj5zO OIGQ== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of claudius.heine.ext@siemens.com designates 194.138.37.40 as permitted sender) smtp.mailfrom=claudius.heine.ext@siemens.com Return-Path: Received: from gecko.sbs.de (gecko.sbs.de. [194.138.37.40]) by gmr-mx.google.com with ESMTPS id y42si761600wry.5.2018.02.15.05.17.07 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 15 Feb 2018 05:17:07 -0800 (PST) Received-SPF: pass (google.com: domain of claudius.heine.ext@siemens.com designates 194.138.37.40 as permitted sender) client-ip=194.138.37.40; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of claudius.heine.ext@siemens.com designates 194.138.37.40 as permitted sender) smtp.mailfrom=claudius.heine.ext@siemens.com Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by gecko.sbs.de (8.15.2/8.15.2) with ESMTPS id w1FDH7HO013322 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Thu, 15 Feb 2018 14:17:07 +0100 Received: from [139.25.68.223] (linux-ses-ext02.ppmd.siemens.net [139.25.68.223]) by mail1.sbs.de (8.15.2/8.15.2) with ESMTP id w1FDH7fP024235 for ; Thu, 15 Feb 2018 14:17:07 +0100 Subject: Re: [PATCH 2/2] centralize multistrap configuration generation To: isar-users@googlegroups.com References: <20180214131509.16361-1-claudius.heine.ext@siemens.com> <20180214131509.16361-3-claudius.heine.ext@siemens.com> <1eaf1493-e834-ce50-9e75-ff5795348b58@ilbers.de> <923f3293-320b-9172-14aa-3b3a372a1dfa@siemens.com> <20180215112741.GB5374@yssyq.radix50.net> From: Claudius Heine Message-ID: Date: Thu, 15 Feb 2018 14:17:07 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180215112741.GB5374@yssyq.radix50.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-TUID: +lxNrmcDsaSi Hi Baurzhan, On 02/15/2018 12:27 PM, Baurzhan Ismagulov wrote: > On Thu, Feb 15, 2018 at 11:15:02AM +0100, Jan Kiszka wrote: >>> That shows to me that upstream might be interested in some of these >>> improvements we would need to implement. >> >> Exactly. We should really use the community-proven, continuously tested >> official approach of Debian, in that in a way that it foresees for it. >> >> Let's bury multistrap. Its a dead horse we rode to long now. > > First off, thanks for cutting the many lines of code not being referred to :) . > > Regarding multistrap, both approaches have advantages and disadvantages. > Moreover, there are other implementations, such as cdebootstrap. I am not sure about cdebootstrap, while I do like a C implementation more the one in shell scripts, I am skeptical about its maintenance and if they even accept contributions. Cdebootstrap last version is 0.7.7 from 2017-03-08 while debootstrap latest version 1.0.93 is from 2017-12-07. I could not find any repository containing the development history of cdebootstrap, while debootstraps repo is here [1]. cdebootstrap seems to be developed by the package maintainer himself while debootstrap is maintained and developed by multiple people. If we don't plan on developing our own debian bootstrap method, then trying to get changes pushed there seems to have a higher chance of success then with cdebootstrap. [1] https://anonscm.debian.org/cgit/d-i/debootstrap.git > > > Multistrap is currently useful in the following ways: > > 1. Generate the list of packages to install using several apt repos. > > 2. Provide the package paths to download from apt repos. > > 3. Generate the base system from several apt repos. > > Unfortunately, all three seem to be unique among the three candidates. > > > (1) and (2) are necessary for reproducibility. My preferred solution would be > to use an apt library that would do that for us (e.g., extract it from apt, > extend python-debian, or look whether aptly provides that). Moving to > *debootstrap would require solving those in a community-unmaintained way for > some time. > > (3) is useful for people with customizations cutting off significant dependency > chains from Debian (like SLIND did with Perl dependencies). Moving to > *debootstrap would mean first installing those, then apt-getting our layers > above the base system, then removing the packages that are no more required. IMO apt-preferences could help here. Prios >= 1000 would remove already installed packages. regards, Claudius > > This was the main reason for Neil Williams to create multistrap. After trying > to wrap debootstrap for some time, he ended up with problems not solvable in > that way (not sure which, maybe some kinds of circular dependencies or > dependencies on exact package versions). So, it would be wise to consider his > experience here. > > That said, on DebConf17, he told us that that use case is not interesting for > him any more, advised to use debootstrap, and said that he doesn't support > multistrap any more. > > Regarding maintaining multistrap for some time: I personally don't like Perl. > That said, Alex looked at that recently; it's some reasonable wrapping around > apt-get. If the problem in the end is solved with apt-get, we should possibly > evaluate that, too. > > > Regarding debootstrap, the problem is that it is implemented in shell, which is > horrible for any serious improvements. Thus the question about cdebootstrap. > > > All in all, I'd like to see a solution that would offer serious benefits while > not introducing new problems. Currently, multistrap is an internal issue not > directly affecting user-visible features. There are many features we can do for > far better Debian support. Changing one bit with another, not better one > wouldn't change the big picture. So, I'd rather use this opportunity to start a > bigger effort of defining the requirements, choosing the tools to merge with, > provide a working PoC, and start working with Debian on reusability of those > tools in Isar. IMHO, *debootstrap alone wouldn't bring major architectural > improvements. > > > With kind regards, > Baurzhan. > -- 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