Le 06/07/2021 à 20:28, David Cantrell a écrit :
On Tue, Jul 06, 2021 at 12:51:59PM -0400, Neal Gompa wrote:
> On Tue, Jul 6, 2021 at 12:29 PM David Cantrell <dcantrell(a)redhat.com>
> wrote:
>>
>> On Thu, Jun 24, 2021 at 11:50:18AM -0400, Ben Cotton wrote:
>> >https://fedoraproject.org/wiki/Changes/libmemcached-awesome
>> >
>> >== Summary ==
>> >Switch from libmemcached to libmemcached-awesome
>> >
>> >== Owner ==
>> >* Name: [[User:Remi| Remi Collet]]
>> >* Email: remi at fedoraproject dot org
>> >
>> >== Detailed Description ==
>> >
>> >libmemcache 1.0.18 was released in February 2014, so hasn't received
>> >an update for 7 years.
>> >
>> >libmemcache-awesome is a fork providing same libraries, tools with
>> >API/ABI compatibility.
>> >
>> >== Benefit to Fedora ==
>> >
>> >Rely on a maintained project.
>> >
>> >
>> >
>> >== Scope ==
>> >* Proposal owners: Check Koschei status. Test with latest version to
>> >ensure compatibility. Work with upstream on bug fixing. Needed mass
>> >rebuild (C extensions) done by change owner.
>> >
>> >* Other developers: N/A (not a System Wide Change)
>> >* Release engineering:
>> >* Policies and guidelines: N/A (not a System Wide Change)
>> >* Trademark approval: N/A (not needed for this Change)
>> >
>> >
>> >== Upgrade/compatibility impact ==
>> >N/A (not a System Wide Change)
>> >
>> >== How To Test ==
>> >
>> >* install and play with your application
>> >
>> >== User Experience ==
>> >
>> >Developers and system administrators will have the great benefit or
>> >running a maintained library.
>> >
>> >
>> >== Dependencies ==
>> >
>> >All php-* packages (and some *-php)
>> >
>> >== Contingency Plan ==
>> >* Contingency mechanism: Drop not compatible packages.
>> >* Contingency deadline: N/A (not a System Wide Change)
>> >* Blocks release? N/A (not a System Wide Change)
>> >
>> >== Documentation ==
>> >
>> >* [
https://awesomized.github.io/libmemcached/ Upstream documentation]
>> >
>>
>> The change proposal indicates this is a drop-in API replacement
>> project, but will this introduce a new package named
>> 'libmemcached-awesome' and we let libmemcached go out to pasture? Or
>> is this changing the Source0 of the libmemcached package to just use
>> this new upstream?
>>
>> If the former, will the new package provide proper Provides/Conflicts
>> against the existing libmemcached package or are there plans to allow
>> both to be installed at the same time?
>
> From what I can tell, you can't have both installed in parallel, so I
> think I'd prefer to see the Source0 in libmemcached change to the fork
> rather than introducing a new source package and complicating things.
That's more or less the direction I was going with this thought.
If we are fairly confident libmemcached is dead upstream, then I see
no reason to just replace Source0 with the active project. On the
other hand, we have seen projects come back from what appears to be a
dead upstream and then you have a name conflict and/or confusion.
Also we do have naming policy for Fedora packages that at least
encourages the package name to match the upstream project name in
cases where that will work.
I don't know the state of libmemcached and whether or not it will come
back to life (or if it's even dead upstream). With that in mind, I
would prefer to see:
* Addition of libmemcached-awesome as a new package
* libmemcached-awesome Provides libmemcached
* libmemcached-awesome Obsoletes libmemcached
* Orphan libmemcached
That the plan (new package named, as the project, libmemcached-awesome)
FYI, the rename was an explicit requirement of the old project author.
Additionally, if any packages carry a Requires or dynamic dependency
on libmemcached, those should be updated to libmemcached-awesome. The
lazy way would be to add Epoch: 1 to libmemcached-awesome and let
libmemcached fade away.
libmemcached will be retired, everything provided by "libmemcached" is
now provided byt the new one
Remi