From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6948863191726161920 X-Received: by 2002:a17:906:c297:: with SMTP id r23mr915164ejz.48.1617957008837; Fri, 09 Apr 2021 01:30:08 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a05:6402:4c2:: with SMTP id n2ls2953052edw.2.gmail; Fri, 09 Apr 2021 01:30:07 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw4trpflS5UAdVt9pokoQ7MIDVmWKrlGF9JCqrwcRYhq9EKYCn+6DVXtPJ06hPLZFjEsN3p X-Received: by 2002:a50:ec92:: with SMTP id e18mr6550880edr.246.1617957007902; Fri, 09 Apr 2021 01:30:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1617957007; cv=none; d=google.com; s=arc-20160816; b=T/+eLiVIKVn99Gse9M/wf9uhRhYRU/kEomRYKglDLwuholDEwgU2x0XJveASdafE+L VaMgYfeOfWMi9wp2mUVLQu7XPd/QeUjU+0o5cx9wdJe9M0I+tEehRT3DAoblb3aVgJSe 6tEV75bPZwrONEt4oXEeOhIkR5Cy97zcYpFQsxvfUQipZE+KQXX2EpeSI1jC3qbYioZV La4f/yGITTiJkS4aZXoJYCG1INqjZWN5RhXreL0GrIbVPVBJJXJJknrrvaGwPHauScR0 0/OC20LJy5WWbwtiQy4jJuUN1cL7rdX4zYUCmbT/bSYy4bPIUok1VihYHL80LS+FBB+X iFZg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date; bh=T4oLrDkOAU42e+wA98Pq+X1dOrxWIQlQsc9bJYNSBVk=; b=gryFhUT83Fac+7LvTm3UvSEo6CcY9Qz0WPj0InAM3vkiuB+Kt3THcwF/axvJMzoxuh ZkqXfh097F+OY7uJaE6L0r3yI+fHFMHr9p8+Qr9wMEdx1oGxpxgUzTsUy9A4vUYtJkbL 00kBfaCsECwe5jlL87I2juXzZSo5KXv1EKqLk8QmbgTMbEfhT+kkYjn7zHp16fRoxOv8 Jn8Zjq1fJw2MyHCZCBdKKKF4r2zYVSkN/dyLONGKSxs/biHRjnspAvFELAALzV8OqAVO oEZMazER1HngPX6OS25pqeOIMG2XvCiMVsXL5QuzyAVYxakOCFr/5k3BtVnER/LY9svu Mddw== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 194.138.37.40 as permitted sender) smtp.mailfrom=henning.schild@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 c12si338025eds.0.2021.04.09.01.30.07 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 09 Apr 2021 01:30:07 -0700 (PDT) Received-SPF: pass (google.com: domain of henning.schild@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 henning.schild@siemens.com designates 194.138.37.40 as permitted sender) smtp.mailfrom=henning.schild@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by gecko.sbs.de (8.15.2/8.15.2) with ESMTPS id 1398U78r026185 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Fri, 9 Apr 2021 10:30:07 +0200 Received: from md1za8fc.ad001.siemens.net ([139.22.114.252]) by mail1.sbs.de (8.15.2/8.15.2) with ESMTP id 1398U7KY000401; Fri, 9 Apr 2021 10:30:07 +0200 Date: Fri, 9 Apr 2021 10:30:05 +0200 From: Henning Schild To: Jan Kiszka Cc: isar-users Subject: Re: isar-exclude-docs vs. openjdk et al. Message-ID: <20210409103005.0d904d99@md1za8fc.ad001.siemens.net> In-Reply-To: <51fed86f-7579-3f42-4780-c84e18bf4117@siemens.com> References: <51fed86f-7579-3f42-4780-c84e18bf4117@siemens.com> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-TUID: +VvkPCfh4plq Hi, not sure that doc purging is really allowed or whether we are messing with stuff we better should not mess with. Am Thu, 8 Apr 2021 20:54:28 +0200 schrieb Jan Kiszka : > Hi all, > > there seems to be a conceptual issue with isar-exclude-docs purging > documents in its postinst hook: If other packages are configured after > isar-exclude-docs and those packages expects certain doc paths to be > still there, see openjdk [1], they will fail. > > How to solve that? > - maintain a list of conflicting packages in that recipe? This is going to be cumbersome but when having a packet that needs its docs, we probably should not install that cleaner. > - convert the package to a post-process hook? would still break apt-get update of packages that need their docs > - find a way to ensure a compatible ordering when running our > postinst? again going to break apt-get Looking at this one example it does not really need its docs, it just expects them in "its own hack". My guess is that the problem can be reproduced in a ubuntu container (where the no-docs stuff is coming from), and can be used to report an issue so that the update-alternatives script looks for the files conditionally. Or maybe write a patch for that package and MR it on salsa directly. If you are installing java you probably can store a few MB of docs ;) Henning > > Jan > > [1] > https://groups.google.com/g/isar-users/c/uIHgzvCGLwU/m/tuOchY6BAgAJ >