Thread: RPM Morgue

Re: Craig Ringer 2018-06-25 <CAMsr+YHGvn-7nyFUncdVHR_Q5i2Kc19jy_RAvmt-g9O5iMKUqg@mail.gmail.com>
> 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.

Fwiw, the reason I set it up is because our repo software (reprepro)
doesn't support keeping the past N versions of every package around.
The yum repo keeps the last 3 versions in place, I believe. But of
course that doesn't help if $customer didn't upgrade for $long.

Christoph

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 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'm not against keeping the old package, but there are two things:

* We need to ask sysadmins team, because 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 are worth the hassle.

Again, I'm not against the idea as long as you can convince sysadmin team, and
also write scripts to pull the packages :)

Cheers,
--
Devrim Gündüz
EnterpriseDB: https://www.enterprisedb.com
PostgreSQL Consultant, Red Hat Certified Engineer
Twitter: @DevrimGunduz , @DevrimGunduzTR

Re: Devrim Gündüz 2018-06-27 <76dfe96c8abe24e76e0c8f27a1537ae9f8c811c2.camel@gunduz.org>
> I'm not against keeping the old package, but there are two things:
> 
> * We need to ask sysadmins team, because this means a lot of extra disk space.

The apt morgue is 74 GB atm. It's not mirrored anywhere - which isn't
ideal, but the at means we only need to keep an eye on the local disk
space, and not on N mirror hosts which all might have slightly
different limits.

The initial discussion with the sysadmins was that everyone kind of
agreed that the service is useful, but we couldn't settle for any
definition of what resources should be allocated for the next N years.
So in the end I just put it somewhere, and that's where it's living
now. (I don't blame them for that, it's difficult to work with
statements like "this could be any size, because we don't know how
many packages there will be in 3 years".)

Christoph

Re: GOLLET Nicolas 2018-06-28 <164461a65cc.e862b2a0141287.1906369810237409971@ng.pe>
> I had also thought 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:

Why not include everything? Filtering is extra effort, and even if you
get the filters right, they will soon become outdated.

Christoph