Bug 23732 - postgresql10 packaged incorrectly should be removed from Cauldron
Summary: postgresql10 packaged incorrectly should be removed from Cauldron
Alias: None
Product: Mageia
Classification: Unclassified
Component: Security (show other bugs)
Version: Cauldron
Hardware: All Linux
Priority: release_blocker critical
Target Milestone: Mageia 7
Assignee: Marc Krämer
QA Contact: Sec team
Depends on:
Reported: 2018-10-19 00:59 CEST by David Walser
Modified: 2019-02-03 00:25 CET (History)
4 users (show)

See Also:
Source RPM: postgresql10
Status comment:


Description David Walser 2018-10-19 00:59:18 CEST
Forgive me if some discussion has taken place on the dev ml to say it's OK; I'm way behind on reading it.

The postgresql10 package appears to have been created based on Fedora's package instead of ours.  Unless we've decided to switch to their packaging model, the package should be removed so a new attempt can be made to package it correctly.
David Walser 2018-10-19 00:59:39 CEST

Target Milestone: --- => Mageia 7
CC: (none) => pkg-bugs

Comment 1 Thomas Backlund 2018-10-19 07:19:02 CEST
And since we dont have had 10 in any stable release, maybe we should just skip it and package the brand new 11 instead :)

CC: (none) => tmb

Comment 2 David Walser 2018-10-19 15:46:35 CEST
Agreed, we only want to ship the newest branch, and the newest that the previous stable release had (9.6) for transition purposes.
David Walser 2018-12-16 22:31:26 CET

Priority: Normal => release_blocker
Severity: normal => critical

Comment 3 David Walser 2018-12-26 02:33:39 CET
We need to package 11.1:
Comment 4 Marc Krämer 2019-01-25 01:13:10 CET
what is the difference between mga packaging and fedora you are referencing here?

I've had a look in pg9.6, which is packaged the same way.

The current maintainer is joequant, isn't it him, who should do this?

CC: (none) => mageia

Comment 5 David Walser 2019-01-25 04:02:08 CET
Our packaging is completely different from Fedora's.  They only package one version of PostgreSQL, but the package sources actually bundle the older version from the previous distro release, allowing it to automatically import the database from the old version, migrate it, and update you to the current PostgreSQL version.  That's not all bad, but it makes packaging a pain as you have to deal with the real version and the bundled old version.

What Mageia/Mandriva's packages have done is keep the different versions in separate packages, and we just support staying on the latest version from the previous distro version, as an older option on the current distro version, and allow sysadmins to manually do the migration to the newer version when they want to.  As such, having to versions packaged, both provide the same libraries, but we make the names of the library packages from the two versions different (the newer one is a generic name, like libpq{soversion}, and the older one is versioned, like libpq9.4_{soversion}), so they don't conflict, and anything else that wants the libs can work with the newer package's libs, regardless.

So, like I said, it's vastly different, and we're not going to switch to the Fedora model without discussing it first and coming to a reasoned consensus.

As for who should do it, anyone can do it.  It's just a matter of taking the time to examine how we've done it in the past and replicating that.  As for joequant, he's the one that blindly imported postgresql10 from Fedora and ignored people pointing out that this was not correct (and that was not an isolated incident), and that's how we got in this mess in the first place.  So it'd be nice if he would listen, learn how we do things, and fix it, but past history hasn't given much hope that that's going to happen.
Comment 6 Marc Krämer 2019-01-25 13:55:20 CET
ok, understood. If I find some time, I'll have a look on this, I hope this one is not as complex as the mariadb package :)
Comment 7 Marc Krämer 2019-01-28 19:57:46 CET
I've pushed a first version for pg11.1
The main part is based on our old versions. Where does the library major come from? I didn't find a source why the library version is different to the package version.

Feel free to make changes to the package, if needed.

Assignee: sysadmin-bugs => mageia

Comment 8 David Walser 2019-01-29 00:11:35 CET
For the newer postgresql package it should just be libpq5.  The last digit of the number on the older (in this case 9.6) package, I'm not sure where it comes from.

From a quick glance the one thing I noticed is 11 should obsolete 10 (really just temporarily, to get rid of it), but *not* 9.6 as we need to keep that (or 9.5 which doesn't exist).

Thanks for working on this!
Comment 9 Marc Krämer 2019-01-29 19:00:01 CET
ok, changes applied. new version pushed.
Comment 10 David Walser 2019-01-31 15:03:05 CET
Hi Marc.  I see you've gone back and forth with the package name.  Unless upstream has changed something again, it should be postgresql11.  With version 10 they changed the versioning scheme, and now stable branches just have a major number, and the bugfix updates change the minor number.
Comment 11 Marc Krämer 2019-01-31 15:14:00 CET
ah... that was the information which was missing to me. Ok, so I change it back (again).
Comment 12 Marc Krämer 2019-01-31 15:23:09 CET
so, we still need an admin to remove pg10 - it is still on the mirrors.

what about the mentioned rpmsrate?!
Comment 13 David Walser 2019-01-31 15:31:07 CET
rpmsrate will need to say postgresql11, and if it's in prefer.vendor.list it'll need to be changed there too.

As long as all of the pg10 packages are obsoleted, the SRPM will be removed automatically the next time the sysadmins run the cleaning script.
Comment 14 Marc Krämer 2019-01-31 15:33:54 CET
for rpmsrate, this is new to me, maybe you can change this?
Comment 15 David Walser 2019-01-31 15:39:14 CET
See r1362133, just pushed.
Comment 16 David GEIGER 2019-01-31 16:26:43 CET
all postgresql10 pkgs are not yet obsoleted and now we have in repo postgresql11.1 (wrong 11.1)

CC: (none) => geiger.david68210

Comment 17 David Walser 2019-02-03 00:25:47 CET
All the incorrect stuff has been removed by Thomas Backlund.  Thanks!!!

Resolution: (none) => FIXED

Note You need to log in before you can comment on or make changes to this bug.