On Tue, Jul 06, 2021 at 12:51:59PM -0400, Neal Gompa wrote:
On Tue, Jul 6, 2021 at 12:29 PM David Cantrell
> On Thu, Jun 24, 2021 at 11:50:18AM -0400, Ben Cotton wrote:
> >== 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/
> 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
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.
None of the above is mentioned in the change proposal and since the
change is about the mechanics of how to do this, I'd like to see it
David Cantrell <dcantrell(a)redhat.com>
Red Hat, Inc. | Boston, MA | EST5EDT