From: voidlinux-github@inbox.vuxu.org
To: ml@inbox.vuxu.org
Subject: Re: protobuf: update to 3.11.2
Date: Sat, 01 Feb 2020 15:58:38 +0100 [thread overview]
Message-ID: <20200201145838.lY_11R6RMOaxdY7s6i6lS1pIEbiron7ZLQ9m-s9IxTk@z> (raw)
In-Reply-To: <gh-mailinglist-notifications-41a7ca26-5023-4802-975b-f1789d68868e-void-packages-18691@inbox.vuxu.org>
[-- Attachment #1: Type: text/plain, Size: 1650 bytes --]
New comment by ahesford on void-packages repository
https://github.com/void-linux/void-packages/pull/18691#issuecomment-581037963
Comment:
> The revbumps should each be in separate commits. The versioned sub-packages were introduced to be able to install two versions of the library at the same time and avoid staging on the build servers so they should probably be kept. The replaces is incorrect in any case I think.
Please hold. I'm locally testing rework based on your suggestions and what I've seen with boost packaging:
* Keep libprotobuf18 and libprotoc18
* Version all existing protobuf subpackages:
- protobuf -> protobuf18
- protobuf-lite -> protobuf18-lite
- libprotoc-devel -> libprotoc18-devel
* Rename libprotobuf-lite18 -> libprotobuf18-lite; add a replaces declaration in the subpackage for this name change (this is easier to parse in directory listings, it fits with the protobuf -> protobuf18 change, and makes logical sense because the library is the light version of protobuf 18)
* Create new, non-versioned (sub)packages protobuf{,-devel,lite} and libprotoc-devel for protobuf 3.11.2
* Create new, versioned subpackages libprotobuf22{,-lite} and libprotoc22
* Add conflicts with the unversioned new packages in protobuf18{,-devel} and libprotoc18-devel
In future updates, the procedure would look the same: migrate the unversioned packages to protobuf22 or libprotoc22, create a new unversioned master package with {-devel,-lite} and libprotoc-devel subpackages, and create new versioned subpackages for the shared libraries.
Does this seem reasonable? When my local tests pass, I'll push them here.
next prev parent reply other threads:[~2020-02-01 14:58 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-31 16:57 [PR PATCH] " voidlinux-github
2020-01-31 17:46 ` [PR PATCH] [Updated] " voidlinux-github
2020-01-31 17:49 ` voidlinux-github
2020-01-31 21:30 ` voidlinux-github
2020-02-01 1:38 ` voidlinux-github
2020-02-01 14:57 ` voidlinux-github
2020-02-01 14:58 ` voidlinux-github [this message]
2020-02-01 14:58 ` voidlinux-github
2020-02-01 20:16 ` [PR PATCH] [Updated] " voidlinux-github
2020-02-01 20:46 ` voidlinux-github
2020-02-01 21:03 ` [PR PATCH] [Updated] " voidlinux-github
2020-02-01 22:09 ` voidlinux-github
2020-02-01 22:25 ` [PR PATCH] [Updated] " voidlinux-github
2020-02-10 21:34 ` voidlinux-github
2020-02-21 17:17 ` ahesford
2020-02-29 3:43 ` [PR PATCH] [Merged]: " the-maldridge
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=20200201145838.lY_11R6RMOaxdY7s6i6lS1pIEbiron7ZLQ9m-s9IxTk@z \
--to=voidlinux-github@inbox.vuxu.org \
--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).