2008/6/5 Alexander Kahl <akahl@xxxxxxxxxxxxxx>: > one subpackage needs php-sqlite which has been deactivated in favor of > php-pdo's sqlite support, If that module has a reason for requiring php-sqlite and no upstream has no plans to move it to use php-pdo, then I guess it's better to not package it > another one depends on php-pecl-ibm_db2 no one > has packaged yet If it has an acceptable license you could submit that one for review as well. if you do not feel like maintaining one more package, do not package this > and the last one depends on php-oci8 which cannot be > provided at all because it is proprietary software. Well, it seems the php package is compiled with MSSQL support, which is no more open source than Oracle... I'm not sure why php-oci8 is not in packaged, but of course you can't activate this subpackage until the situation changes. All in all, I think that for all these three subpackages you can avoid building them without a significant impact on the framework feature set. You can provide a simple method for rebuilding the SRPM with those skipped parts, but that's really up to you. just my 0.02 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
