From: q66 <q66@users.noreply.github.com>
To: ml@inbox.vuxu.org
Subject: Re: [PR PATCH] [Closed]: protobuf: restructure and update to 3.12.1
Date: Sat, 23 May 2020 05:55:13 +0200 [thread overview]
Message-ID: <20200523035513.6hP3DcgkBqO8HQ2PjCKp-O7oguquDv0RL2HL2-6H8WQ@z> (raw)
In-Reply-To: <gh-mailinglist-notifications-41a7ca26-5023-4802-975b-f1789d68868e-void-packages-22175@inbox.vuxu.org>
[-- Attachment #1: Type: text/plain, Size: 2048 bytes --]
There's a closed pull request on the void-packages repository
protobuf: restructure and update to 3.12.1
https://github.com/void-linux/void-packages/pull/22175
Description:
This package updates `protobuf` to 3.12.1, which causes an SO version bump that ripples through a bunch of dependents, as always. I've made a few changes in the package structure:
1. Move unversioned `protobuf` and `protobuf-devel` (which was SO version 22) to versioned `protobuf22{,-devel}`; this mirrors the previous move from unversioned to SO version 18.
2. Do *NOT* create a versioned `protobuf22-lite` subpackage. There is a versioned `protobuf18-lite`, but it is just a meta that pulls in `libprotobuf18-lite`, so it is pointless. No need to repeat that mistake for `protobuf22`.
3. Create versioned `protobuf23` and subpackages that follow the same structure as `protobuf22`, but using Protocol Buffers version 3.12.1 with SO version 23. This *will not provied* the unversioned packages that `protobuf22` used to.
4. Create meta-packages `protobuf`, `protobuf-devel`, `protobuf-lite` and `libprotoc-devel` that pull in the right versioned packages.
In the last update, there was a big dance to rename the unversioned `protobuf` subpackages from PB version 3.7.1 (SO version 18) to versioned `protobuf18` and the like, then create new unversioned packages for SO version 22 provided by PB version 3.11.x. With a standalone meta, we create the new versioned packages *once*, and just bump the dependents in the `protobuf` meta-package to point to the latest one. This mimics the LLVM meta/provider structure and makes updates a little less painful.
I'm currently rebuilding all of the revbumps on all supported archs because Travis will time out; when the builds are all done, I'll drop draft status and post an update.
@the-maldridge: I mentioned this on IRC, but let me know if you are swamped with other things and want me to take ownership of the `protobuf` packages. I use them regularly and have a vested interest in tracking new updates.
prev parent reply other threads:[~2020-05-23 3:55 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-21 18:33 [PR PATCH] " ahesford
2020-05-21 23:38 ` [PR PATCH] [Updated] " ahesford
2020-05-21 23:48 ` ahesford
2020-05-22 0:31 ` q66
2020-05-22 2:04 ` q66
2020-05-22 2:09 ` ahesford
2020-05-22 2:14 ` [PR PATCH] [Updated] " ahesford
2020-05-22 2:58 ` ahesford
2020-05-22 3:32 ` ahesford
2020-05-23 3:17 ` ahesford
2020-05-23 3:55 ` q66 [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200523035513.6hP3DcgkBqO8HQ2PjCKp-O7oguquDv0RL2HL2-6H8WQ@z \
--to=q66@users.noreply.github.com \
--cc=ml@inbox.vuxu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).