From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6948863191726161920 X-Received: by 2002:a5d:480a:: with SMTP id l10mr30949841wrq.261.1618252725095; Mon, 12 Apr 2021 11:38:45 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a05:6000:162d:: with SMTP id v13ls509480wrb.1.gmail; Mon, 12 Apr 2021 11:38:44 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwUWf8dChUf0oms2lxKI847Hctsvw1OppeTBzKkXM1PFO0mgYD+m48ZdhnEsAhIh/rJbCQw X-Received: by 2002:adf:9cc1:: with SMTP id h1mr32389737wre.135.1618252724240; Mon, 12 Apr 2021 11:38:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1618252724; cv=none; d=google.com; s=arc-20160816; b=ZqF1PV09g1LCDaOLRMFgp8CnuKoSp7Xxwh3ZahzO1VhyLfryF8wiyp6gjmtmI96B9U i3LhEPamcFWIRDCBHnWpmGKEOGqlVwJNgYbs6rjd0IRPiStNVb/eGzk3p7QxwJgDiNog PegkpBzsH0D4Qc3quZoKkIg48HihCezJJ+AGjeeWeRjYruN44SY5nnnBXegwReKg8+6O Yr2ZRxLRKG2CXp7dgmH5sYU6oXgMF9UD2KOwKBIJinyfdMHqU+86A1N0k1Ni4nDOCHX4 jLJo4Y8Nz3zne9tAz7B89PAxqUqc+lYwhZyAzL+dV5us2zmhAsxv4GAjMmRxoWZL/WO7 BhOQ== 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=+AHLwxkTBd4ijr56adYWFsS+XdJcVTiPAqUk0rqm+Rg=; b=a19GvKxyhgksy1OZd8qBUlWy5FMI3zVnOQnN1AUSt/EMJKoPWm5TlVuSxO4EWK9hER e3F0NMroxNCrF1tK81JrLaeuo3w+PqufxAryUK2KWoTal6PVtwhoIt+ChNkYd2CYcBaW D+dzrTqsEBTnAjDZ3dz3R4L70w8wVL04+OlbHA7avSf9Epe71mBejfnFeyA9Bskc5oXf sYag/BC0DNRWNYZJB7CpZV6sZa6TlbCgdd6L8SSimvnta6IJA+5tr4DbvmNVmFVoThjx q71fiMXv/oqIlIar+gIDFXYXFLdTuAHMJB2AgF2eBN9PvcF6AlcX+sHnEUKTnQqtME4e bBYA== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 194.138.37.39 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 lizzard.sbs.de (lizzard.sbs.de. [194.138.37.39]) by gmr-mx.google.com with ESMTPS id c6si8847wmr.2.2021.04.12.11.38.44 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Apr 2021 11:38:44 -0700 (PDT) Received-SPF: pass (google.com: domain of henning.schild@siemens.com designates 194.138.37.39 as permitted sender) client-ip=194.138.37.39; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 194.138.37.39 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 lizzard.sbs.de (8.15.2/8.15.2) with ESMTPS id 13CIchLM015687 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Mon, 12 Apr 2021 20:38:44 +0200 Received: from md1za8fc.ad001.siemens.net ([139.22.41.180]) by mail1.sbs.de (8.15.2/8.15.2) with ESMTP id 13CIZ2jS009120; Mon, 12 Apr 2021 20:35:02 +0200 Date: Mon, 12 Apr 2021 20:35:01 +0200 From: Henning Schild To: "[ext] Silvano Cirujano Cuesta" Cc: isar-users@googlegroups.com Subject: Re: isar-exclude-docs vs. openjdk et al. Message-ID: <20210412203501.24b71403@md1za8fc.ad001.siemens.net> In-Reply-To: References: <51fed86f-7579-3f42-4780-c84e18bf4117@siemens.com> <20210409103005.0d904d99@md1za8fc.ad001.siemens.net> <265b98fc-524f-7f7e-164c-0215f5e9d494@siemens.com> <20210410104618.790f06b3@md1za8fc.ad001.siemens.net> 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: jBYSjDkVBHOj Am Mon, 12 Apr 2021 10:47:14 +0200 schrieb "[ext] Silvano Cirujano Cuesta" : > On 10/04/2021 10:46, [ext] Henning Schild wrote: > > Am Fri, 9 Apr 2021 15:01:48 +0200 > > schrieb Jan Kiszka : > > > >> On 09.04.21 10:30, Henning Schild wrote: > >>> 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 > >>> ;) > >> > >> Yeah, the case that triggered that is a bug, not a real scenario. > >> I'm lacking a feeling how common that combination is and if there > >> might be realistic combinations as well. > > > > My guess is that it would be best to try and mainline that package > > right into debian. They could use it for their containers, offer it > > for their users and will maintain the list of conflicts or detect > > such bugs. > > It's not only an ISAR issue. > Just try to install openjdk-11-jre-headless on a debian:buster-slim > image to reproduce it. Yes that particular slim container contains a similar hack to remove docs. But that is not coming from any package ... so Isar is even better here ;). Maybe upstream should have a "slim" package and they could maintain conflicts. root@1b57a090701a:/etc/dpkg/dpkg.cfg.d# dpkg -S /etc/dpkg/dpkg.cfg.d/docker dpkg-query: no path found matching pattern /etc/dpkg/dpkg.cfg.d/docker Henning > I'll report the bug on the Debian openjdk package, since the images > being provided by Docker can be considered the de-facto standard > (even provided by Debian maintainers Tianon Gravi [1] and Paul > Tagliamonte [2]). > > I'd rather wait for them to react to it before deciding which way we > go. > > Curious about how those images are being created? See here: > https://github.com/debuerreotype/debuerreotype > > Silvano > > [1] https://qa.debian.org/developer.php?login=tianon > [2] https://qa.debian.org/developer.php?login=paultag > > > > > As far as i remember the configs came from ubuntu, not sure they > > have it packaged or just smuggle it into their containers. > > > > That said, i bet there are packages that have runtime deps on > > (their) docs. Doc readers or applications that opt for cat ing a > > file on --help, probably not made up ... > > > > Henning > > > >> Jan > >> > >>> Henning > >>> > >>>> > >>>> Jan > >>>> > >>>> [1] > >>>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fg%2Fisar-users%2Fc%2FuIHgzvCGLwU%2Fm%2FtuOchY6BAgAJ&data=04%7C01%7Csilvano.cirujano-cuesta%40siemens.com%7C86e2085237e3487d4c8608d8fbfea912%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637536418464481337%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=f%2F4dVdp5tYLFm5KbqvFdNE7rXLMUiMP5hnI8oGcmPC4%3D&reserved=0 > >>>> > >>> > >> > >> > > >