From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6522397978051739648 X-Received: by 10.80.146.109 with SMTP id j42mr126885eda.6.1518694065029; Thu, 15 Feb 2018 03:27:45 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 10.80.133.197 with SMTP id q5ls1775248edh.1.gmail; Thu, 15 Feb 2018 03:27:44 -0800 (PST) X-Google-Smtp-Source: AH8x226hZF/Rb/rEq2yBbLkqejiUPEQAbBK8XRSIvg+vYr9OdoarEYYafPIYu59IZ2FhTDro0vhm X-Received: by 10.80.242.130 with SMTP id f2mr679629edm.5.1518694064472; Thu, 15 Feb 2018 03:27:44 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518694064; cv=none; d=google.com; s=arc-20160816; b=ZZlU/7R7U+dX2+AnTghZwct6atfGQV9xo4iHbT4Ohsmto6nHjTboHspqfG2TFDYbAb Xw7QFOZDmrxY2RvRM8/dkytr+iPqtqFCgVgicLxTFEFOmKhw5ElX+sxlvP5m21CKd4n2 cpoKmHpq5K1BikbZrEk3ftcsxgPTFvWFEg6Ju5T1EDH/1cwrJfqQ97FzQXS3v8Dt5kJ/ umI+h1S0M4TXXEcxLSMsvr07izdfe/2vRk7WsM5zCKvbyU0u5mXA5xK0OkE965Z4RVBs ljHA/T/osYxKls6bHuHwy5s674e3AcI15vAlPOKkuvTXluRiHu7R3JbtVy3wANDGcDtz boRw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=user-agent:in-reply-to:content-disposition:mime-version:references :mail-followup-to:message-id:subject:to:from:date :arc-authentication-results; bh=jL3uP4HCgYdrVuQ5TjNNmdmMoPZ53Yqb3e4q4o3unO0=; b=dSxj1P0r/FOds0xuyLCgtJATVuCaAMQxe6aw4ew4+xhWa7QrIf8T0MZ0sV+cuaw/ON oyFXIGAqP7IOA+oUJMjYncO4S0Opr1835/mU7qyb9VaR3YHZQ21+/ErkjTA0iGg1cH4F 2UpdDyPxi7mre306gdo2/BoTp5p6qhSYfLvwy1wePu6ESgflq4s6xoKc0eeyQHSl4mlt +/BraasiFXDTIolBo4TlTRtEQbs5cbZGOuRbpn9DI+kB8WXOAc0kOptvKD3YUPABUGxc PQJ8RbQDYlBfmeqrKzhYy9d6QBqumJsyY+JtRvkxHWC1Z3W0GNRcHzPNOF4Snx89RL7F 7IYQ== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=neutral (google.com: 85.214.62.211 is neither permitted nor denied by best guess record for domain of ibr@radix50.net) smtp.mailfrom=ibr@radix50.net Return-Path: Received: from aqmola.ilbers.de (aqmola.ilbers.de. [85.214.62.211]) by gmr-mx.google.com with ESMTPS id z1si251938edh.3.2018.02.15.03.27.44 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 15 Feb 2018 03:27:44 -0800 (PST) Received-SPF: neutral (google.com: 85.214.62.211 is neither permitted nor denied by best guess record for domain of ibr@radix50.net) client-ip=85.214.62.211; Authentication-Results: gmr-mx.google.com; spf=neutral (google.com: 85.214.62.211 is neither permitted nor denied by best guess record for domain of ibr@radix50.net) smtp.mailfrom=ibr@radix50.net Received: from yssyq.radix50.net (p2E51BAA3.dip0.t-ipconnect.de [46.81.186.163]) (authenticated bits=0) by aqmola.ilbers.de (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id w1FBRgSA014102 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 15 Feb 2018 12:27:43 +0100 Received: from yssyq.radix50.net (localhost [127.0.0.1]) by yssyq.radix50.net (8.14.4/8.14.4/Debian-8) with ESMTP id w1FBRgre007640 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 15 Feb 2018 12:27:42 +0100 Received: (from ibr@localhost) by yssyq.radix50.net (8.14.4/8.14.4/Submit) id w1FBRgQP007639 for isar-users@googlegroups.com; Thu, 15 Feb 2018 12:27:42 +0100 Date: Thu, 15 Feb 2018 12:27:42 +0100 From: Baurzhan Ismagulov To: isar-users@googlegroups.com Subject: Re: [PATCH 2/2] centralize multistrap configuration generation Message-ID: <20180215112741.GB5374@yssyq.radix50.net> Mail-Followup-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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-TUID: t8t0SuzJz7QE 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. 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. 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.