Description of problem:
Machine last udated 6.6, update at day later - 7.6 failed transaction check:
Running transaction check
ERROR with transaction check vs depsolve:
php(api) = 20100412-x86-64 is needed by (installed) cups-php-1:1.5.4-20.fc18.x86_64
php(zend-abi) = 20100525-x86-64 is needed by (installed) cups-php-1:1.5.4-20.fc18.x86_64
Please report this error in https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&version=rawhide&component=yum
** Found 7 pre-existing rpmdb problem(s), 'yum check' output follows:
1:cups-php-1.5.4-20.fc18.x86_64 has missing requires of cups = ('1', '1.5.4', '20.fc18')
1:cups-php-1.5.4-20.fc18.x86_64 has missing requires of cups-libs = ('1', '1.5.4', '20.fc18')
1:cups-php-1.5.4-20.fc18.x86_64 has missing requires of libgnutls.so.26()(64bit)
1:cups-php-1.5.4-20.fc18.x86_64 has missing requires of php(api) = ('0', '20100412', 'x86-64')
1:cups-php-1.5.4-20.fc18.x86_64 has missing requires of php(zend-abi) = ('0', '20100525', 'x86-64')
libxfce4menu-4.6.2-3.fc17.x86_64 has missing requires of libxfce4util.so.4()(64bit)
policycoreutils-restorecond-2.1.14-45.fc19.x86_64 is a duplicate with policycoreutils-restorecond-2.1.13-27.1.fc17.x86_64
Version-Release number of selected component (if applicable):
updated f19 beta
After removal of php and cups-php update passed.
Erasing : 1:cups-php-1.5.4-20.fc18.x86_64
Erasing : php-5.5.0-0.7.RC2.fc19.x86_64
Just note - this system was updated from f18 by fedup
Reassiging to cups, as this is a sub-package of cups.
IIRC, this extension is no more provided. So I think this is not a bug.
Jiri, have you been actually using the cups-php (PHP CUPS extension module) ?
This module has been dropped by CUPS upstream since cups-1.6 and has been picked by cups-filters project. I tried to build it once I packaged cups-filters (and today once more) but with no luck - the code needs some updates. I spoke to Tim and he thinks the module has never been particularly useful and perhaps we could let it die for now and maybe try to ship it with cups-filters once somebody explicitly requests it.
So I'll just make cups-filters-libs Obsolete&Provide cups-php for now (without actually providing the module).
In such case it should be ok to add Obsoletes. So the underlying package will be removed during update. Then it should be ok.
> So I'll just make cups-filters-libs Obsolete&Provide cups-php for now
> (without actually providing the module).
I mostly disagree. If the package disappear, without being replaced, it should not be obsoleted/provided.
Yes, this cause a trouble during update, but this also raises user attention to fix it.
Discussed at 2013-06-10 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-06-10/f19final-blocker-review-4.2013-06-10-16.01.log.txt . Rejected as a blocker: we only block on upgrades of the default GNOME package set, default KDE package set and minimal install package set, and cups-php isn't in any of those. Variant package sets are only on a 'best effort' basis.
Note that this can be fixed for repo-based upgrades with a post-release update (media-based upgrades aren't working right now anyway...), and can be trivially worked around by just removing cups-php prior to the upgrade attempt, which is more or less what the 'fix' will cause to happen anyway.
I've added only
Obsoletes: cups-php < 1:1.6.0-1
cups-filters-1.0.34-7.fc19 has been submitted as an update for Fedora 19.
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing cups-filters-1.0.34-7.fc19'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
cups-filters-1.0.34-7.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.