Обсуждение: Proposal for "common" repository

Hi,

(First of all: This is not an April 1st thing)

Currently we have two types of RPMs: Some of them are tied to a specific
PostgreSQL version, and some of them are not (I will call them "common").

These common packages bring in two problems:

* The current build infrastructure builds them again and again for all
distros+testing repos. For example, Proj is built on v12, v12testing, v11,
v11testing, v10, v10testing, v9.6, v9.6testing, and v9.5 repositories. (I'll
probably stop 9.6 and 10 testing repos soon, but that is not the topic right
now.)

* 1 common package is kept in 9 different directories (see above), which
consumes a lot of disk space. It generates lots of FTP and rsync traffic.

So, to avoid these two issues, I'm inclined to make a few changes:

Git repo:

- Rename the current "common" directory (which handles Makefiles) to "global"
directory (to avoid confusion)

- Make sure that common and "non-common" packages are in separate directories
in git, so I'll move many packages to a new subdir

- Adjust makefiles in global, and invent new directories for those common RPMs
(Should be easy by altering _srcrpmdir and _rpmdir variables there), and new
targets for those common RPMs.

Build servers:

- Update build *and sync* scripts for the new layout
- Update repo files for the new layout

So, this will definitely break lots of things, but I feel like I have to bite
this bullet anyway.

Any comments, objections?

Regards,
--
Devrim Gündüz
Open Source Solution Architect, Red Hat Certified Engineer
Twitter: @DevrimGunduz , @DevrimGunduzTR

On Wed, 2020-04-01 at 12:12 +0100, Devrim Gündüz wrote:
> So, to avoid these two issues, I'm inclined to make a few changes:
> 
> Git repo:
> 
> - Rename the current "common" directory (which handles Makefiles) to "global"
> directory (to avoid confusion)
> 
> - Make sure that common and "non-common" packages are in separate directories
> in git, so I'll move many packages to a new subdir
> 
> - Adjust makefiles in global, and invent new directories for those common RPMs
> (Should be easy by altering _srcrpmdir and _rpmdir variables there), and new
> targets for those common RPMs.
> 
> So, this will definitely break lots of things, but I feel like I have to bite
> this bullet anyway.
> 
> Any comments, objections?

Will this break regular updates like "yum upgrade"?

If yes, then I am a bit doubtful.
That would make many people unhappy and lead to people running outdated
minor releases.

Yours,
Laurenz Albe

Hi,

On Wed, 2020-04-01 at 13:20 +0200, Laurenz Albe wrote:
> Will this break regular updates like "yum upgrade"?

No, if they use the new repo RPM. This is my current plan:

==================================================
# PGDG Fedora testing - common repository

[PGDGCommonTestingRPM]
name=PostgreSQL common RPMs for Fedora $releasever - $basearch Testing Repo
baseurl=https://download.postgresql.org/pub/repos/yum/testing/common/fedora/fedora-$releasever-$basearch
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-PGDG
==================================================

> If yes, then I am a bit doubtful.
> That would make many people unhappy and lead to people running outdated
> minor releases.

I'm open to ideas in here in order to minimize the breakage.

Regards,
--
Devrim Gündüz
Open Source Solution Architect, Red Hat Certified Engineer
Twitter: @DevrimGunduz , @DevrimGunduzTR

Hi again,

On Wed, 2020-04-01 at 12:40 +0100, Devrim Gündüz wrote:
> No, if they use the new repo RPM.

Just to clarify: Users will be able to get PostgreSQL updates, and many other
"non-common" updates even if they don't update the repo files. However, (for
example) PostGIS updates will fail, because they won't be able to get new Proj
packages when I update them. At that point, they will have to update the repo
file.

So the major user base won't be affected. I'm more concerned about the folks
who build their own packages from our repo. Their scripts will be broken.

Regards,

--
Devrim Gündüz
Open Source Solution Architect, Red Hat Certified Engineer
Twitter: @DevrimGunduz , @DevrimGunduzTR