From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6491554293275951104 X-Received: by 10.80.151.161 with SMTP id e30mr371123edb.4.1513001561437; Mon, 11 Dec 2017 06:12:41 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 10.80.241.28 with SMTP id w28ls3505158edl.0.gmail; Mon, 11 Dec 2017 06:12:41 -0800 (PST) X-Google-Smtp-Source: ACJfBos7gUlaBr9PUt1Z3PvsXEzOJtekq4/F1IVJEMfjil3mSkHg7xQBx8lvsgWPLEvj6i6/ec/m X-Received: by 10.80.174.140 with SMTP id e12mr366294edd.12.1513001561023; Mon, 11 Dec 2017 06:12:41 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1513001560; cv=none; d=google.com; s=arc-20160816; b=oyJCp0rsRgQzEzT4i555I63GI4/kBkD7Z3p1lCVtwZ1vbjNU5c1WijYN6The8eNyBP DFsYOWtPHoTitv11KaWc0egH9fJ49bWfWU6g2LY1xfuTEuGvS9PsMWPQWCj0a4ftO1s2 q/w2OiXXa0Sva4bdVy4aNxiNdgP6xPOCQ8t6DCo3Bk4lTuGGa14zOx2EuJ4vvyhiPnhN ezIdp1JHXEniYQoz1rc6lCA7H2Cmx/83o8HEMvSkM1zBU+/0N7Biw50TOreBxgQDOJi8 dN3/wev3ZCQIrQzzoL4U3XxFXBmgajbU7fs6tuYU3Tte++Tj+Rx2tD71pqXz89gPRE+b ejKw== 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=430VMhG/PJQdcveN7EgsvS03AUPpP+I/2H8FP0Vl7zo=; b=yTNSZPS8FsLnFIs2zNV/MjIoik2KzqVoQdbqEcjr0a/8GWFvbn8qSnGB6Kgdd4d72F Ahi/oMyG2bPxSSUaDxd0Rl+eVLGGwVkL0HfUCeF9FiKwqa7ri5ZKoETaKUCeSqZ67Z5C smNApSdB0QCJd54bb+BzjwAWSUxliurEWZnhiSCoNHuc8jpXtVwPOCE55s6YQ1jcHox7 YIk3d4p0LNGz16oPoUBHNXSK/Mh3Dmk2A2m9LyRXA2NYyDAOPrug4g5OTrqOUrjIVHQX IpWj3NCimcJ1GyWbZfyVTLkoZLyeSmvxzvS0ZR2L0TprHO0kpKdKtv7J04ush00tIQ7t 2YJw== 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 h45si1414889eda.2.2017.12.11.06.12.40 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 Dec 2017 06:12:40 -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 [10.0.2.15] (client.yota.ru [188.162.64.66] (may be forged)) (authenticated bits=0) by aqmola.ilbers.de (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id vBBECbEm024219 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Mon, 11 Dec 2017 15:12:39 +0100 Subject: Re: [PATCH 3/4 v2] buildchroot: Add prepare and cleanup tasks To: isar-users@googlegroups.com References: <20171211133732.kmsyncnhm3mmq24e@MD1KR9XC.ww002.siemens.net> From: Alexander Smirnov Message-ID: <18a32ba4-fe05-9812-7a24-0011490a749b@ilbers.de> Date: Mon, 11 Dec 2017 17:12:31 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20171211133732.kmsyncnhm3mmq24e@MD1KR9XC.ww002.siemens.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-TUID: Q5awM52uUP9a On 12/11/2017 04:37 PM, Storm, Christian (CT RDA ITP SES-DE) wrote: >>>>> 2. 'do_cleanup': This task is executed after all the packages are >>>>> deployed. Some notes: >>>>> - This task also should not have stamp. >>>>> - This task depends from the recipes listed in IMAGE_INSTALL. >>>> >>>> This breaks build dependencies when building two packages from >>>> source (same example I've given in other posts as well): >>>> >>>> Consider A-dev required by B, both to be built from source. B cannot >>>> install the A-dev.deb since B depending on A-dev's deploy_deb() and >>>> installing it the ugly way via dpkg -i (as no other option is >>>> currently available in Isar) puts B as late in the task order so >>>> that it's git repo is not mounted anymore. Failure. >>>> >>>> If A-dev installs it's produced .deb as last step in its >>>> dpkg_runbuild(), which is also ugly, then there's a potential race >>>> in dpkg. Failure. >>> >>> Seems I don't fully understand your usecase, could you please comment >>> if it's correct: >>> >>> 1. You have two Isar recipes A and B that build packages from source >>> code. >>> >>> 2. After building of package A, apart from binary A, A-dev also >>> provided. >>> >>> 3. Package B depends on A-dev. >>> >>> Also, have you added dependency from A in B recipe? >> >> Dependencies will not help here, Isar simply does not support that >> case ... yet. >> You have B depending on A both at runtime and on build-time. So you need >> a buildchroot to build A in. And for B you need a buildchroot which has >> A installed. >> >> To get the buildchroot for B you either have to install A into its own >> buildchroot or multistrap again. >> >> I think Christian currently installs A, but with "dpkg -i". I think >> multistrapping again would be overkill. IMHO the best solution would be >> to install such packages in buildchroot with apt-get, after they have >> been repreproed to the "Isar" repo. > > Yes, right, ugly, I know, but currently the only way to reflect my use > case -- which Henning described very well -- in Isar. Without this hack > or preferably a proper solution to this, I cannot use Isar for my use > case. Since this change, in fact, I can't. > Sorry, but I still don't understand how this patch brakes your build because it doesn't influence on dependencies at all. If you need strict order for packages to be built, then anyway you have to specify this in recipe: In recipe B: DEPENDS += "A" do_build[deptask] = "do_build" It would be very helpful for me if you could provide recipes and workaround. > So, in some sense I relied on a workaround for a missing feature that's > now broken and hence you may rightfully argue that nothing can break a > missing feature. Nonetheless, it did so for me and my hack :) > > >> I suggested improvements on "[PATCH 0/4 v5] Isar apt deployment" but >> the feedback was delayed until a v2. >> >> Essentially deploy_deb needs to reprepro, do_populate needs to go away, >> builchroot needs aptsources=Isar in its multistrap.conf. Now the >> apt-get in build.sh should work. > > I very much appreciate a proper solution to this to resume using Isar > for my use case. Could handle this after your top-prio issues. Alex