Thanks for the reply Remi! I'm switching the thread to php-devel (from
devel). Responses inline below.
On Mon, 2017-01-16 at 08:44 +0100, Remi Collet wrote:
> Le 16/01/2017 à 07:06, Randy Barlow a écrit :
> > Hello Fedora devs!
> > I recently started working on getting Ampache packaged for Fedora,
> > it turns out it is no small feat. There are two problems:
> > 0) 5 of the packages have been abandoned upstream, and have been
> > replaced with different packages that are now recommended. Ampache
> > aware of this and does intend to switch, but at this time they
> > depend on these 5 packages. Would this be a blocker to getting
> > in, or can we just plan to retire these packages once upstream is
> > to use their new replacements?
> I don't think this is a blocker.
> Of course you can retire them when no more used by Ampache.
> BTW, perhaps another way is to use bundled versions for these, to not
> expose them as something "stable and maintained".
Bundling them is an interesting idea. It'll save some time, and it'll
make it easier to do the packaging initially. Perhaps I'll go this
> > Fedora!
> Perhaps php-devel(a)lists.fedoraproject.org worth to be used.
> I also recommend you read the SIG pages (especially the packaging
> for autoloaders, and how we get rid of the composer autoloader)
> => https://fedoraproject.org/wiki/SIGs/PHP
> Shawn Iwinski can probably help you on the guzzle stuff.
I actually just discovered the PHP packaging tips page last night that
mentions a bit about the autoloaders. It might be helpeful to include
the information from https://fedoraproject.org/wiki/SIGs/PHP/PackagingTips in https://fedoraproject.org/wiki/Packaging:PHP, or possibly link
to the former from the latter. I had only discovered the latter link
when making my first few packages, so knowing about the tips would have
If anyone would like to help me, this page tracks the packages that are
It seems like a good idea to drop "php-oauth"  from Fedora, as it is
old and no longer maintained upstream and there are no packages
depending on it:
[fkooman@fralen ~]$ sudo dnf repoquery --whatrequires php-oauth
Last metadata expiration check: 1:15:18 ago on Mon Jan 9 11:18:04 2017.
Working again on multi-versions of the same library.
We start to have more and more libraries available in multiple versions.
In a consumer package:
If composer.json states foo: "~1 | ~2"
As v1 and v2 are different major version, we are going to have 2
different packages installed in different tree.
php-foo1, with autoloader in /usr/share/php/foo1/autoload.php
php-foo2, with autoloader in /usr/share/php/foo2/autoload.php
So you MUST allow both version ONLY if your autoloader is aware of each
BuildRequires: php-composer(foo) < 3
BuildRequires: php-composer(foo) >= 1
Requires: php-composer(foo) < 3
Requires: php-composer(foo) >= 1
And in autoloader
Do not allow multi major versions if your composer if not aware.
Do not add Conflicts on composer virtual name.
Conflicts: php-composer(foo) >= 3
This is bad, as if php-foo3 exists, it will be installed in another
tree, so won't be used, and no conflicts needed.
Comment (before I try to add something in the packaging tips page) ?
(in my repo)
- twig 1 and 2 are allowed, as autoloader is aware of both versions
- symfony 3 is not allowed (despite supported by upstream) as the
autoloader is only aware of v2