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 1fYUtD-0005GU-HI for pgsql-pkg-yum@arkaria.postgresql.org; Thu, 28 Jun 2018 11:15:03 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1fYUtB-0004tM-3Y for pgsql-pkg-yum@arkaria.postgresql.org; Thu, 28 Jun 2018 11:15:01 +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 1fYUtA-0004tF-RV for pgsql-pkg-yum@lists.postgresql.org; Thu, 28 Jun 2018 11:15:01 +0000 Received: from sender-of-o51.zoho.com ([135.84.80.216]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fYUt7-0002o1-Q7 for pgsql-pkg-yum@postgresql.org; Thu, 28 Jun 2018 11:14:59 +0000 Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1530184492497254.42340531655486; Thu, 28 Jun 2018 04:14:52 -0700 (PDT) Date: Thu, 28 Jun 2018 13:14:52 +0200 From: GOLLET Nicolas To: "\"Devrim G?nd?z\"" Cc: "\"Craig Ringer\"" , "\"pgsql-pkg-yum\"" Message-Id: <164461a65cc.e862b2a0141287.1906369810237409971@ng.pe> In-Reply-To: <76dfe96c8abe24e76e0c8f27a1537ae9f8c811c2.camel@gunduz.org> References: <76dfe96c8abe24e76e0c8f27a1537ae9f8c811c2.camel@gunduz.org> Subject: Re: RPM Morgue MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_458702_455916636.1530184492492" X-Priority: Medium User-Agent: Zoho Mail X-Mailer: Zoho Mail List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk ------=_Part_458702_455916636.1530184492492 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Craig, I had also thought that setting up a public morgue would be a goo= d thing, I recently set up an unofficial public morgue (WIP): http://pgyum-= morgue.ng.pe/ (WIP) I'm missing some RPM, if you want us to work together o= n setting it up I'm available;) I had thought not to put all the packages i= n the morgue but the most important ones: - postgresql (RPMs but also an ar= chive containing all RPMs (libs, contrib, debuginfo, ...) by version (WIP).= - slony - postgis ... ? Classified by architecture and RHLE version... See= you soon! ++ Nicolas ---- On mer., 27 juin 2018 01:40:54 +0200=C2=A0Devrim= G=C3=BCnd=C3=BCz wrote ---- Hi Craig, On Mon, 2018-06-= 25 at 09:42 +0800, Craig Ringer wrote: > 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 instal= l them. This is a *lifesaver* when > trying to examine a core file a custom= er system where debuginfo wasn't > installed, or trying to reproduce a subt= le version-specific issue. > > Do you have anything like that? If not, do y= ou have any interest in it? I'd > really like to get something like it goin= g, 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 > inc= remental mode (--update --retain-old-md-by-age=3D5d) to index them. > > So = it doesn't upset https://yum.postgresql.org/, but > https://yum-archive.pos= tgresql.org/ or whatever can keep a deep history of > packages. > > An alte= rnative 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 > yo= u go for infrequent access mode. > > Thoughts? I'm not against keeping the = old package, but there are two things: * We need to ask sysadmins team, bec= ause this means a lot of extra disk space. * Building older packages is not= that hard with the RPMs as you know -- just change the version number, and= run make rpm11 (or whatever). I'm not sure that keeping the old packages a= re worth the hassle. Again, I'm not against the idea as long as you can con= vince sysadmin team, and also write scripts to pull the packages :) Cheers,= -- Devrim G=C3=BCnd=C3=BCz EnterpriseDB: https://www.enterprisedb.com Post= greSQL Consultant, Red Hat Certified Engineer Twitter: @DevrimGunduz , @Dev= rimGunduzTR ------=_Part_458702_455916636.1530184492492 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Hi Craig,

I had also though= t that setting up a public morgue would be a good thing, I recently set up = an unofficial public morgue (WIP): http://pgyum-morgue.ng.pe/ (WIP)

I'm missing some RPM, if you want us to work together on setting it= up I'm available;)
I had thought not to put all the packages= in the morgue but the most important ones:
- postgresql (RPM= s but also an archive containing all RPMs (libs, contrib, debuginfo, ...) b= y version (WIP).
- slony
- postgis
... ?
Classified by architecture and RHLE version...

See you soon!

++

Nicolas


---- On mer., 27 juin = 2018 01:40:54 +0200 Devrim G=C3=BCnd=C3=BCz <devrim@gunduz.org&g= t; wrote ----

Hi Craig,

On Mon, 2018-06-25 at= 09:42 +0800, Craig Ringer wrote:

> The a= pt.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. Th= is 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 i= nterest in it? I'd
> really like to get something like it= going, and rather than creating one
> in-house at 2ndQ w= here nobody else lands up benefiting, it might make sense
&g= t; 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 create= repo_c runs in
> incremental mode (--update --retain-old-= md-by-age=3D5d) to index them.
>
> So i= t doesn't upset = https://yum.postgresql.org/, but
> https://yum-archive.postgre= sql.org/ or whatever can keep a deep history of
> pac= kages.
>
> An alternative is to ditch t= he repo indexing and use an AWS S3 bucket to
> host an un= indexed 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'm= not against keeping the old package, but there are two things:
<= div>
* We need to ask sysadmins team, because this means a l= ot of extra disk space.

* Building older pac= kages is not that hard with the RPMs as you know -- just
cha= nge the version number, and run make rpm11 (or whatever). I'm not sure that=
keeping the old packages are worth the hassle.

Again, I'm not against the idea as long as you can convi= nce sysadmin team, and
also write scripts to pull the packag= es :)

Cheers,
--
Devrim G=C3=BCnd=C3=BCz
PostgreSQL Consultant, Red Hat Certified Engineer
Twitter: @DevrimGunduz , @DevrimGunduzTR


------=_Part_458702_455916636.1530184492492--