From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6795913180905209856 X-Received: by 2002:a05:6512:247:: with SMTP id b7mr2492437lfo.21.1584440897725; Tue, 17 Mar 2020 03:28:17 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a2e:9a8a:: with SMTP id p10ls1229587lji.9.gmail; Tue, 17 Mar 2020 03:28:17 -0700 (PDT) X-Google-Smtp-Source: ADFU+vsxuc9Dxp+TL3a/tqVDxm2gV4PCxzqlEG6yj5qmCZ8k7NtB06uMNuKQtblGMCJ06SJV3gpe X-Received: by 2002:a2e:9a55:: with SMTP id k21mr1641852ljj.130.1584440896945; Tue, 17 Mar 2020 03:28:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1584440896; cv=none; d=google.com; s=arc-20160816; b=RFVHa+lmi4bRwihwZdZLfMYSyqWc8joOn3wZONVEz//GCZnASujTbQTrT3bf0a0CFP ORxgNHjm1oVzbZzQqQWxAEMbcvX9wRBAN9LINhT/BBM1mYt0BcsmOof44M1eCp80zVay yxdTzaR3JRjpxVPubdIKUKaUf5yQelS5OaMLptPq99DMU5VWWzhsYNZvZeRzW94/7jxB N4jnAx97c4blxV9vw19KWobyReOveAgc2/lKGEshX6rETx5ST+U/djdMptpMudV6cbDb QaYcWRB1IWJ7igq3ihrfA5P5eKrpt9aK+b69QIaT/AcRe5LXAcaSatKoL8g2YIsuI8oQ RFfQ== 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:cc:to:subject; bh=hbDcicQIXsukVzPTrV6L5qostkpL8exHX+3zCNGNI24=; b=yutDKbmWjreQTLfJNFcbc9eQNCGJ2RaheRu+BQXaOn17eQ7b6Ih18evaAsNdMXpXmX /c7rx2WSPshpbaDP6r5ATV5MhtQ7KqaQxppgFghVW1RHvcKfkeF1xkTD26O+znPGUGAu LXX79YhAeJW5NCaRSUV9NINPxnmjHhz9I8ZO5DlAScZxHsJeSEPtyh80AxNROn5LfU5m bfZZ2hWKlc4x4PtMEzSTIZKdyMK3iBvDiOc4nBTX3kweeAsNYXvEIIh3KyI/VIDGcpSq /s1xd/ZGX64fZ8CvAtW/NKXfN1p9AIUwPv7qe9ogBs0spe9WfmN0fTQoIa0Fj6B9vfqX amTw== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 194.138.37.40 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Return-Path: Received: from gecko.sbs.de (gecko.sbs.de. [194.138.37.40]) by gmr-mx.google.com with ESMTPS id a21si160023lff.3.2020.03.17.03.28.16 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Mar 2020 03:28:16 -0700 (PDT) Received-SPF: pass (google.com: domain of jan.kiszka@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 jan.kiszka@siemens.com designates 194.138.37.40 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by gecko.sbs.de (8.15.2/8.15.2) with ESMTPS id 02HASF1r024618 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Tue, 17 Mar 2020 11:28:15 +0100 Received: from [167.87.42.164] ([167.87.42.164]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id 02HASEgd020414; Tue, 17 Mar 2020 11:28:14 +0100 Subject: Re: [RFC 0/2] Remove Packages during Postprocessing To: Gylstorff Quirin , Henning Schild Cc: isar-users@googlegroups.com References: <20200221145348.24250-1-Quirin.Gylstorff@siemens.com> <20200224152416.2aab3ec9@md1za8fc.ad001.siemens.net> <20200225141006.452e4b64@md1za8fc.ad001.siemens.net> <789f5ab1-983a-5005-715f-eb45f6620227@siemens.com> From: Jan Kiszka Message-ID: Date: Tue, 17 Mar 2020 11:28:12 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <789f5ab1-983a-5005-715f-eb45f6620227@siemens.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-TUID: rNbDFP0beprd On 17.03.20 11:23, Gylstorff Quirin wrote: > > > On 2/25/20 2:10 PM, Henning Schild wrote: >> Am Tue, 25 Feb 2020 06:43:55 +0100 >> schrieb Gylstorff Quirin : >> >>> On 2/24/20 3:24 PM, Henning Schild wrote: >>>> Hi, >>>> >>>> my opinion on that is clear. Fix it upstream or live with those >>>> packages. You are either on a distro or fiddle around and tune >>>> everything until you are the only one on the planet testing your >>>> setup. That is Isar vs. yocto ... whoever thinks they _need_ that >>>> should maybe think again. If they need it they can put it into >>>> their own layer or use yocto ;). >>>> I do not think upstream should carry such hacky features unless we >>>> get better reasoning ... Removing "required" packages has the >>>> potential to break your image in funny ways ... that is much more >>>> expensive than a few MB disc space. All affected packages are >>>> likely already cleared and vulnerabilty monitored by someone else, >>>> find that someone and share the cost! >>>> >>>> Henning >>> >>> Hi Henning, >>> >>> I understand your concern and I think you are right. But some people >>> already hack the build process in similar ways and this is a way to >>> give them some support. >> >> I guess it might be a good idea to tell those hackers to comment here >> or share their reasons with you. My guess is that their need is >> questionable and they did not fully understand the consequences. It >> should probably be discarded as premature optimization and removed from >> the downstream layer, instead of added upstream. >> >> Even if they carefully looked at the consequences for the packages they >> remove, a generic upstream feature would ease the hack for people less >> careful. > > FYI > > I got the same patch yesterday again for stripping a rescue system to > fit into a NOR Flash. > We should move on with the series, looking into technical issues (if any). I do think such a functionality is better provided upstream than hacked up multiple times downstream. Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux