Received: from malur.postgresql.org ([2a02:16a8:dc51::56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fXGWZ-0005S9-3G for pgsql-pkg-yum@arkaria.postgresql.org; Mon, 25 Jun 2018 01:42:35 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1fXGWX-0002EZ-QV for pgsql-pkg-yum@arkaria.postgresql.org; Mon, 25 Jun 2018 01:42:33 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fXGWX-0002ES-Id for pgsql-pkg-yum@lists.postgresql.org; Mon, 25 Jun 2018 01:42:33 +0000 Received: from mail-vk0-x22f.google.com ([2607:f8b0:400c:c05::22f]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1fXGWU-00017Q-L0 for pgsql-pkg-yum@postgresql.org; Mon, 25 Jun 2018 01:42:32 +0000 Received: by mail-vk0-x22f.google.com with SMTP id n81-v6so847656vke.6 for ; Sun, 24 Jun 2018 18:42:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=UEdiBrAGhvdrqYEv8Do2bwxMJ35NZoSC/DvV7Ve6Dm4=; b=p7hdGggshM+2byTHuFg9OmPN6cYcJBqxJtd9CH2ns2fdhnbb96gD25jGwtyZQtOe6c iVy1Msqbm+Hf/uZciie/YRAJtD1G6p8hKRyGuHLAXlm/vSFS9vz2qr2NnxtHSHYRVVR1 b+drwi7AuDc5ZAmz655y1hx9TmdC4MX5Dc/Ypt9hc/e8DMd7Qbg0oLBOTrkPgCv0lu8n h5kbwTgHl1f3xJwjw2e1S6C7XyrKUqepcvHF5UMVnX68scK2cL9ik7+Tfg1NKiH3rAEM BvonwdJm+ye1TpPvFGze/ze9lPWW8II7Qwpk5sQqArOIH8eVm2r6Ay13MImOejrHLR0q ki5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=UEdiBrAGhvdrqYEv8Do2bwxMJ35NZoSC/DvV7Ve6Dm4=; b=hKCjOPPp4YcAjei/N+eFx03tFeNkkf7aL2BwC0f+MxwOBuXz3TwRYEkfxrz7Al8jTN Ey0A3cikEoXcMqt8y3hxnpl9CijP4XG1RpsK2tvds12JDnpA+CsJAJTrEd8Qlz8OmIKd d1t3pHWE0rzwiEB5xUbEpE4q3duS1HQXzd0gCCC7IxjaKAnlgkQ8b312SIt+U+llP5rL MtidebmtWIrIDTjTBhinB5IK5U2gbFdF3rSk4LLNXOCkoZInBRXKIEejTYPi9BZSlknZ GXjfGEo0q6i0367k8cOJSSL7MDCu5ITN9HhbHgTWGULn5Dgz7jB+PqhdPXm2TTGVcLmV XfDA== X-Gm-Message-State: APt69E09di+i+6RH0EykXDCPOnnTlT5jWKyuJohx17aDhAaz0CAKds2o pE603JW1+IXqyZcsjF6Ywm5QgjTWi6SAq9e/5NRV5LneA9o= X-Google-Smtp-Source: AAOMgpd6JEX113eIGesQW6WvRw7TULcbiWFjByz1y/ancGPNrjNg7PR+S5iSVCMcThz/fKqwRLX5q8oiI2Yu51PGNsc= X-Received: by 2002:a1f:dc85:: with SMTP id t127-v6mr4558644vkg.120.1529890949304; Sun, 24 Jun 2018 18:42:29 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9f:276a:0:0:0:0:0 with HTTP; Sun, 24 Jun 2018 18:42:28 -0700 (PDT) From: Craig Ringer Date: Mon, 25 Jun 2018 09:42:28 +0800 Message-ID: Subject: RPM Morgue To: =?UTF-8?B?RGV2cmltIEfDvG5kw7x6?= , pgsql-pkg-yum Content-Type: multipart/alternative; boundary="0000000000009434bc056f6d7ecf" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --0000000000009434bc056f6d7ecf Content-Type: text/plain; charset="UTF-8" Devrim, team: The apt.postgresql.org crew have a package morgue for old versions at atalia.postgresql.org/morgue/ . It's not a full repo, but you can fish out needed packages manually and install them. This is a *lifesaver* when trying to examine a core file a customer system where debuginfo wasn't installed, or trying to reproduce a subtle version-specific issue. Do you have anything like that? If not, do you have any interest in it? I'd really like to get something like it going, and rather than creating one in-house at 2ndQ where nobody else lands up benefiting, it might make sense to help out with one for the community. What I'm thinking of is a selective rsync to an archive repo, where packages get copied but never get deleted, then createrepo_c runs in incremental mode (--update --retain-old-md-by-age=5d) to index them. So it doesn't upset https://yum.postgresql.org/, but https://yum-archive.postgresql.org/ or whatever can keep a deep history of packages. An alternative is to ditch the repo indexing and use an AWS S3 bucket to host an unindexed package slush pile, like the apt morgue. createrepo can't run sensibly on s3-hosted files. But s3 is cheap - 2c/gb/month, or less if you go for infrequent access mode. Thoughts? I can always set up my own mirror inhouse for 2ndQ, but I'd rather work with you. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services --0000000000009434bc056f6d7ecf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Devrim, team:

The apt.postgresql.org crew have a package morg= ue for old versions at=C2=A0atalia.postgresql.org/morgue/ . It's not a full repo, but you can= fish out needed packages manually and install them. This is a *lifesaver* = when trying to examine a core file a customer system where debuginfo wasn&#= 39;t installed, or trying to reproduce a subtle version-specific issue.

Do you have anything like that? If not, do you have a= ny interest in it? I'd really like to get something like it going, and = rather than creating one in-house at 2ndQ where nobody else lands up benefi= ting, it might make sense to help out with one for the community.

What I'm thinking of is a selective rsync to an ar= chive repo, where packages get copied but never get deleted, then createrep= o_c runs in incremental mode (--update --retain-old-md-by-age=3D5d) to inde= x them.


An alternative is to ditch the repo indexing and use an AWS S3 bucket to h= ost an unindexed package slush pile, like the apt morgue. createrepo can= 9;t run sensibly on s3-hosted files. But s3 is cheap - 2c/gb/month, or less= if you go for infrequent access mode.

--0000000000009434bc056f6d7ecf--