From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on sa.local.altlinux.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.1 Date: Sat, 13 Jun 2020 21:50:37 +0300 From: Andrey Savchenko To: ALT Linux Team development discussions Message-Id: <20200613215037.8df524060960dbf33fd37479@altlinux.org> In-Reply-To: <20200613174519.GB22306@altlinux.org> References: <20200604195811.3881130-1-vseleznv@altlinux.org> <20200604195811.3881130-2-vseleznv@altlinux.org> <20200605142254.GA4019241@portlab> <20200613174519.GB22306@altlinux.org> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA512"; boundary="Signature=_Sat__13_Jun_2020_21_50_37_+0300_kBj4VIJnzSNYIb3v" Subject: Re: [devel] [PATCH] gb: add gb-task-build-post, optimize packages with identical rebuild X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ALT Linux Team development discussions List-Id: ALT Linux Team development discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jun 2020 18:50:46 -0000 Archived-At: List-Archive: List-Post: --Signature=_Sat__13_Jun_2020_21_50_37_+0300_kBj4VIJnzSNYIb3v Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, 13 Jun 2020 20:45:19 +0300 Dmitry V. Levin wrote: > On Sat, Jun 06, 2020 at 04:42:21PM +0300, Alexey Tourbin wrote: > > On Fri, Jun 5, 2020 at 5:23 PM Vladimir D. Seleznev wrote: > > > > > Introduce task post-build processing. It finds subtasks with pack= age > > > > > rebuild and if the rebuilt packages identical to the same package= s in > > > > > the target repo it optimizes them. > > > > > > > > It doesn't make much sense. When we rebuild a package without chang= ing > > > > the release, we expect something else in the package to change beca= use > > > > of the rebuild (e.g. a binary will be linked with a new library > > > > version). If the package hasn't changed, it is an alarming condition > > > > which indicates that some of the packager's assumptions were wrong > > > > (e.g. the binary actually doesn't link with the library). So should= we > > > > really "optimize" this case? We might as well prohibit it! > > > > > > By "prohibit" you mean make task build fail? I would say that it is > > > unnecessary. It'd produce additional difficulties for maintainers > > > without any profit. > >=20 > > The difficulties are all in the maintainers' heads. > > There must be a valid reason for rebuilding a package. >=20 > Given that rebuilding a package costs so little for the maintainer, > we definitely should reject rebuilds that do not result to changed > packages. There are valid cases when it is impossible to determine beforehand if rebuild will result in changed package or not, e.g. during boost updates. Best regards, Andrew Savchenko --Signature=_Sat__13_Jun_2020_21_50_37_+0300_kBj4VIJnzSNYIb3v Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE63ZIHsdeM+1XgNer9lNaM7oe5I0FAl7lH/0ACgkQ9lNaM7oe 5I2YCA//b+9QisjpG2yrVo7Jj/yUh8J7pl5Ix6zmRcT2TSG9Yw5lsrmZ4dG9c38Q SdzjaaviOSjWPB3ezcY5j2h50HqxQGWB7KmdcjTGKjmmjxKoXOB0FPZNEHhTy7Yc xoyRnlE6R5rxvrzme+H4eSc1V92bM8OjKoFUicYDfqfsxb1LKgWRugk3YPXX7b5b p9MkJwrjSeEgNKuTDZPLWxjpnqgECdJqQJ/kKzWe3RUOX4ON0CkXKh84qosZA1+4 AywgBIOBOFXv0NPrNLXaJIox9cUXY5L6jMRZKpFPfvpZSXguJL6f75djDgGeDem1 Z34N4B80VCTxw0OOXHJquXFjXPtjVhDpsXld7y+0CPIkLY7/CtW7cSSnxrD0Ez8G 2MGJSs9g98N+FjEVLQXRSXlGdVCKDTr9PiWOS8s9SqclvyffWTe7RrupGEa5SJ9V ZOBQCjttvaibsPVZ2e5mtsIwpMAxXj42Sew03l5qlIjOAEuQ+i5hi7qyakVr0IrN CC0t3HvQ7UtqeNHpG5W7S81sSZ/l6KaDu+V9nkyERwgJzDstUNvzB9v7EZLzAUmw OSwj4e1es/V72FNztWx0TIMBF1nPZhvDvtic63M7tBVw3RMXwDOTYffhp3BsBAZv TyrhbmOR6d3OfpuXojnT0BFzNrFtP8L5sFPbsWM9OrWxuZTuGg4= =Mrz8 -----END PGP SIGNATURE----- --Signature=_Sat__13_Jun_2020_21_50_37_+0300_kBj4VIJnzSNYIb3v--