From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6795913180905209856 X-Received: by 2002:adf:ea42:: with SMTP id j2mr5206646wrn.3.1584440631383; Tue, 17 Mar 2020 03:23:51 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a5d:498c:: with SMTP id r12ls10899232wrq.10.gmail; Tue, 17 Mar 2020 03:23:50 -0700 (PDT) X-Google-Smtp-Source: ADFU+vsvsLzs+ilVHoVM0J0jSwDIz+2FTxFZAsut8Z5RMkyc3IH9Q5KqykuOLwhwp1U4Gn/5HpN5 X-Received: by 2002:a5d:440a:: with SMTP id z10mr5342218wrq.177.1584440630725; Tue, 17 Mar 2020 03:23:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1584440630; cv=none; d=google.com; s=arc-20160816; b=KZay/B6cEub2BvS4kOHtMRuSoRUKazb5oa9PXEhZaeeFuyViN/aWZ1WtcIF1Lxktbz O0XdAHE0dyjYuzelyLZQJGLI2+o3+R55xSRNKsRhSrWdNwazOp5KN/6gGmRndyqHkO6i r7Igv1OfebReX4YY2q79tW9WW9ppx21czBTM94wGZFQfd9tLkrFJ5DBo706RH5EX3W5V yM9hYWL2gACPPAONOKraBBYhpNqIT2PPj9djY3fBPSAjWDIJtGe1/lxqeCiPz6X8QYfn Cd/1RY1RJD8yxqIlBUlCfnDZQudRDzFy13gf0/oJ4xHrUuUKoSwPUkROCaCfsklEZmgI PO8w== 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=CZhtHB2prYtmHYkvqcHXT2LuieCMdUm0MQ6ZSRzVjSA=; b=fTBfG/l7VikaoAdC4actAlCRcoFx4k1GBTdz5SOYOxlwv6pw2GfWiJl185CCwU9tN9 CTb7upi7m3WzUwiKtOJt5d/wrf+tjA+0HLRu5w4nN/tszWwalWiBcuE/hDIDcxDOJ06J XjzdlGXcXWhjHIWhZV8U+HvE3HofYtF6lpRJNLRkeJJsVsbPRjLH3ZgUAY/g8ewfFCXe yGxcQZ67+rKaLKgvUZ4St8ztLFcXU+IV0yay8H71DnnPtvEZTglBNX/DWyQTYgrGqFTc VD0jEuZKmu3Hdv1vuffuuYtvjrLS7jCrcFQCLnXv1/G9jn/w3JuT0jYoI/5zPCO2EeiO La0A== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of quirin.gylstorff@siemens.com designates 192.35.17.28 as permitted sender) smtp.mailfrom=quirin.gylstorff@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Return-Path: Received: from goliath.siemens.de (goliath.siemens.de. [192.35.17.28]) by gmr-mx.google.com with ESMTPS id i16si394940wmd.4.2020.03.17.03.23.50 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Mar 2020 03:23:50 -0700 (PDT) Received-SPF: pass (google.com: domain of quirin.gylstorff@siemens.com designates 192.35.17.28 as permitted sender) client-ip=192.35.17.28; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of quirin.gylstorff@siemens.com designates 192.35.17.28 as permitted sender) smtp.mailfrom=quirin.gylstorff@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 goliath.siemens.de (8.15.2/8.15.2) with ESMTPS id 02HANogM002263 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Tue, 17 Mar 2020 11:23:50 +0100 Received: from [167.87.32.240] ([167.87.32.240]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id 02HANnc9012478; Tue, 17 Mar 2020 11:23:50 +0100 Subject: Re: [RFC 0/2] Remove Packages during Postprocessing To: Henning Schild Cc: isar-users@googlegroups.com, jan.kiszka@siemens.com References: <20200221145348.24250-1-Quirin.Gylstorff@siemens.com> <20200224152416.2aab3ec9@md1za8fc.ad001.siemens.net> <20200225141006.452e4b64@md1za8fc.ad001.siemens.net> From: Gylstorff Quirin Message-ID: <789f5ab1-983a-5005-715f-eb45f6620227@siemens.com> Date: Tue, 17 Mar 2020 11:23:49 +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: <20200225141006.452e4b64@md1za8fc.ad001.siemens.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-TUID: f+DSFs2I3eFB 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. Quirin