From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6558372643829972992 X-Received: by 2002:aa7:c24c:: with SMTP id y12-v6mr1200946edo.11.1528294857880; Wed, 06 Jun 2018 07:20:57 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a50:fd17:: with SMTP id i23-v6ls8565395eds.6.gmail; Wed, 06 Jun 2018 07:20:57 -0700 (PDT) X-Google-Smtp-Source: ADUXVKKhpqsZX6SmKl5txixVd3DXO0B3BfciUfEmB3Bp6MAfHPLmCR8RV4U1wRJbeNMppB5HS1ec X-Received: by 2002:a50:fb0e:: with SMTP id d14-v6mr1213439edq.1.1528294857441; Wed, 06 Jun 2018 07:20:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1528294857; cv=none; d=google.com; s=arc-20160816; b=yJ2+aTYDwdzPPsuAg2jbSz93hjthzfuqdPBXpoIBpZ1CzWBpkN1mvdAFF7HB+AOktm Kq406B4azzwHCMAXjXMchLI8AgTTKM/jaxUcfQKFv0LjplpH5UiUnHRsBckCTtdq80zO xRFbmddLgvTgQAvw+VI6xwVnGue1YgGOauz85OzNI7Q1Z4XCbElKZejHqNG1DV2yUZk2 y2tRAjwU3jELoksMyJFC+U7+uCVR/XJiJYN/68uasremrsUGtnSh14X7Csm4KQsoumBh 9PdC1szgxnRGfuZm37abb1hw9giBd46F6QuIAilqBgUP5+5NDrblBibLFvu7z2b330Cv EAfQ== 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:references:cc:to:from:subject :arc-authentication-results; bh=NiXCZka5AJBZXRICJi6vyJzMjNT47QQsZbs0OjZUzsA=; b=rmPr/iTwRsEVsMvrnGzYysuhHEbI31dYh8P4zqqhqIVK1G3rxoCLV2jr9x7n2SZsN/ G32ySJoAa/6eGf6a3RBjmi2FjdlCBX9oxpXQWjfEB5p3kNEWbmdeAIN8ECEo3qdbl7AP tTm+tH1JSUUKO7yvPfoG/mn+4OQfT3HcmnkjwOJcXKYGUgyLINeZ4CfiijCjVcx1NmBs SEuQqvbFUlo34MdjrzxPFyGhI9Y7h1+FW8sn5zIwp/GaAaiANB7N7+vn5pQfvLYqSZoB 0Ow+N9i9kxr+x/zgSLjN1kvZ4moJRPBbLjmI/4lpCheGyVC6XOhrCSy1alRb+FL2CTAh hhmg== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of claudius.heine.ext@siemens.com designates 192.35.17.14 as permitted sender) smtp.mailfrom=claudius.heine.ext@siemens.com Return-Path: Received: from david.siemens.de (david.siemens.de. [192.35.17.14]) by gmr-mx.google.com with ESMTPS id u7-v6si273515edo.2.2018.06.06.07.20.57 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Jun 2018 07:20:57 -0700 (PDT) Received-SPF: pass (google.com: domain of claudius.heine.ext@siemens.com designates 192.35.17.14 as permitted sender) client-ip=192.35.17.14; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of claudius.heine.ext@siemens.com designates 192.35.17.14 as permitted sender) smtp.mailfrom=claudius.heine.ext@siemens.com Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by david.siemens.de (8.15.2/8.15.2) with ESMTPS id w56EKuj7011263 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Wed, 6 Jun 2018 16:20:57 +0200 Received: from [139.25.69.69] (linux-ses-ext02.ppmd.siemens.net [139.25.69.69]) by mail1.sbs.de (8.15.2/8.15.2) with ESMTP id w56EKuLt002595; Wed, 6 Jun 2018 16:20:56 +0200 Subject: Re: [RFC PATCH 0/3] Reproducible build From: Claudius Heine To: isar-users@googlegroups.com Cc: Silvano Cirujano Cuesta References: <3467a5ec-182e-8c9a-cd19-7ad898323be7@siemens.com> <20180523063206.29180-1-claudius.heine.ext@siemens.com> <20180524180027.09b7b880@md1pvb1c.ad001.siemens.net> <3a6032fee718de6cf44fff4e8051a8c7a89a6471.camel@denx.de> <20180604113736.GD5657@yssyq.radix50.net> <3431e051-cdc2-1ba6-8d8f-c426679c6954@siemens.com> <1e8bda03-70e6-93bf-6a30-29740164e83d@siemens.com> Message-ID: <88bd9482-62f3-fe31-28ed-12ccd607db5a@siemens.com> Date: Wed, 6 Jun 2018 16:20:56 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-TUID: vlchRRYctqWx Hi, On 2018-06-06 11:17, [ext] Claudius Heine wrote: > Hi, > > On 2018-06-05 12:42, [ext] Claudius Heine wrote: >> Hi, >> >> On 2018-06-04 18:05, [ext] Claudius Heine wrote: >>> I will try to post a small graphic about this soon. >> >> I attached the design Jan and me came up with yesterday. >> >> Hopefully its understandable enough even with all those arrows >> pointing around. I tried to vary the arrow lines and heads to signify >> dependencies/execution order, using of repositories and deploying >> packages to the repositories. >> >> The main point about this is that it will work with apt preferences >> repository pinning and that we will try to move all installed packages >> to the local cache after every step. >> >> I highlighted the new components in the diagram as green and the >> changed components as light green. >> >> If this is the way we want to go then I would try to get a RFC >> patchset started. > > Unfortunately 'apt-move' has some bugs that make usage with debootstrap > near impossible without some patches. > > The required patches to solve this issue were posted to the debian > mailinglist 5 years ago, so I guess that will not be merged in the near > future [1]. This means apt-move is pretty much dead. > > So we have to find a different solution or need to implement it ourselves. I did some further research into the different solutions for creating apt repositories: 0. apt-move - Would fit our usage very well, but this is effectively dead and cannot be used, because of the unfixed bugs and some missing features. 1. reprepro - We are using in in isar already, but development there seems to be a bit stale [1]. - Fetching the corresponding source packages would need to be implemented by us. 2. apt-ftparchive or dpkg-scanpackages - Can be used to generate Package and Release files, but does not care about creating the pool directory structure - We could implement the missing functionality as well as fetching the corresponding source packages ourselves. 3. mini_dinstall - Implementation of a repository management daemon supporting the official maintenance cycle. - Submitting of package to be added to the repository is done with .changes files, that are generated by building source packages. We would have to generate those files ourselves. But I think that this might get awkward to implement around. 4. aptly - Implemented in Go. I am a bit reluctant of using Go projects, because my experiences have shown that Go applications have the tendency to not care much about reproducibility and stable maintenance. (Importing code directly from github urls without even enforcing commitids???) 5. pulp - Focused on RPM and Puppet, has DEB support with the Note: "WARNING: There may be bugs." I looked at other products as well, but most are just unmaintained for a long time or doesn't solve our issues (mrepo, local-apt-repository). If we don't find a solution that does not require any implementation ourselves, then I would prefer implementing the missing functionality in python instead of shell, with the hope that it becomes easier to maintain. Claudius [1] https://tracker.debian.org/pkg/reprepro -- 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