Spec URL: http://prelive.iconmobile.com/dev31/fedora-icm-repo/Fedora/7/SPECS/php-pear-Propel.spec SRPM URL: http://prelive.iconmobile.com/dev31/fedora-icm-repo/Fedora/7/SRPMS/php-pear-Propel-1.2.1-2.fc7.src.rpm Description: This is a metapackage that installs both Propel's runtime and generator components. Propel is an Object Relational Mapping (ORM) framework for PHP5. It allows you to access your database using a set of objects, providing a simple API for storing and retrieving data. Propel allows you, the web application developer, to work with databases in the same way you work with other classes and objects in PHP. -- I'm still searching for a sponsor.
Updated Spec URL: http://prelive.iconmobile.com/dev31/fedora-icm-repo/Fedora/7/SPECS/php-pear-propel.spec Updated SRPM URL: http://prelive.iconmobile.com/dev31/fedora-icm-repo/Fedora/7/SRPMS/php-pear-propel-1.2.1-3.fc7.src.rpm
Updated Spec URL: http://prelive.iconmobile.com/dev31/fedora-icm-repo/Fedora/7/SPECS/php-pear-propel.spec Updated SRPM URL: http://prelive.iconmobile.com/dev31/fedora-icm-repo/Fedora/7/SRPMS/php-pear-propel-1.2.1-4.fc7.src.rpm Changes: - merged in all metapackages (thus removed bug dependencies) - consequently adapted macros for all shell operations - s/%{buildroot}/$RPM_BUILD_ROOT/
*** Bug 266821 has been marked as a duplicate of this bug. ***
*** Bug 266801 has been marked as a duplicate of this bug. ***
Updated Spec URL: http://prelive.iconmobile.com/dev31/fedora-icm-repo/Fedora/7/SPECS/php-pear-propel.spec Updated SRPM URL: http://prelive.iconmobile.com/dev31/fedora-icm-repo/Fedora/7/SRPMS/php-pear-propel-1.2.1-5.fc7.src.rpm Changes: - made runtime subpackage the main package instead - fixed package ownerships - fixed template script execution permissions
Looks like this depends on php-pear-phing; that should be indicated in this ticket so reviewers know not to look at this package until the other one is done.
Since php-pear-phing is approved, I can review this. But I'm a bit confused; why are there two tarballs which generate two separate packages? I know you originally submitted two packages and then combined them, but I don't see any explanation of why you've done that.
The original idea was to have one combined package containing two pear packages but I realized having those separated can be advantageous for non-development machines where the generator component isn't needed. Do you think I should split up the package again and create another Review Request for the generator component?
ping Jason
Finally have a little more time now... Generally when you have two separate upstream tarballs you make two separate packages; at the very least this lets you release an update or fix to one package without having to regenerate them both. One reason not to do this is when the two packages would depend on each other; in that case it may end up simpler to build both from one srpm. And I guess if the two packages are so inextricably bound that you could never update one without the other then you could probably make a reasonable argument to have them together. But in the end, absent a compelling reason for the two packages to build from one srpm, I'd suggest that they be separate packages.
So, what's going to happen with this package? Did you decide whether or not to split it into two?
Hi Jason, sorry for taking so long. I've realized both packages are even completely independent from each other so I'm facing a new problem now: Who owns /usr/share/pear/propel? The generator component has its own review request as Bug 433045 now, if you're interested. Updated Spec URL: http://akahl.fedorapeople.org/php-pear-propel/php-pear-propel_runtime.spec Updated SRPM URL: http://akahl.fedorapeople.org/php-pear-propel/php-pear-propel_runtime-1.2.1-7.fc8.src.rpm
ping jason
Jason is not really doing any reviews as of late. You kind of missed the window where I had free time.
Finally have some time. This builds OK; rpmlint says: php-pear-propel_runtime.src:106: W: macro-in-%changelog buildroot You need to double percent signs in your changelog so that they aren't expanded. php-pear-propel_runtime.noarch: W: no-documentation which is true; there doesn't seem to be any documentation at all in the tarball. The license is a bit odd. First off, I think it's LGPLv2+, because the version is not specified anywhere and the LGPL allows us to choose any version at all in that case. However, if you look upstream, they say that they've relicensed Apache 2 licenced code to LGPL. I sort of understand what the situation would be if they had licensed to GPL, as only GPLv3 is compatible with ASLv2 so the result would be GPLv3+. But I really don't know about LGPL. Honestly seeing that they've just decided to relicense others code to an incompatible license makes me rather nervous. Blocking legal for input on the license compatibility, and someone should really check with upstream about what version of the LGPL they actually intend.
I see... I'll fix the first rpmlint warning and I've just written to propel-dev about the licensing issue asking for clarification. However at http://propel.phpdb.org/trac/wiki/Users/Introduction/License upstream states, >>Note that the LGPL is a more restrictive license than the Apache 2 license used for Apache Torque, from which Propel is derived. Propel complies with the terms of the Apache license by providing the necessary disclaimer text and not using the name "Torque" or "Apache" in the name.<< What do you think..?
Hi - I'm the lead developer for Propel. We haven't really had licensing questions come up, as is probably not surprising for a small, PHP project. That's not an excuse for having a bad license, merely an explanation of why we could find ourselves in this position now. I will note that I definitely spent some time researching this back in 2002 when the project started -- and know that I talked to the Torque folks about this question -- but I also will concede that there is clearly explicit documentation now indicating that these licenses are incompatible. So, not sure exactly what informed the decision that LGPL was compatible. We would like to resolve this problem (and respect the license of source work!); I am certain that getting the contributors to agree to a license change to a Apache-based license (e.g. PHP license?) will not be a problem. To correct our wiki document, original Propel was based on Torque at a time when I'm quite certain was actually the Apache 1.1 license. My understanding is that Apache 2 license wasn't released until much after original Propel release. I don't think that changes the basic problem here. I will work with the developers to get this resolved in a timely manner.
hmm, it seems both the spec and the srpm have disappeared...
Xavier, the links in comment #12 WFM.
oh, sorry, I didn't catch the change, the URL from comment #12 works for me too, indeed... Sorry for the noise.
(In reply to comment #17) > We would like to resolve this problem (and respect the license of source work!); > I am certain that getting the contributors to agree to a license change to a > Apache-based license (e.g. PHP license?) will not be a problem. Indeed, this seems like the best resolution to this issue.
We've updated our license to LGPLv3. This is currently reflected on our website and will be reflected in the next release. To clarify for the sake of the thread, while FSF doesn't believe the Apache license is compatible w/ LGPLv2, this is not the belief that has been held by Apache. It is true that everyone agrees that version 3 of the LGPL is fine. We've never explicitly specified the version of the LGPL that covered the project; however, we did include 2.x, as that was the current version at the time (and then we got lazy about keeping up). The Propel developers decided that the simplest way to handle this solution was to update the license we were distributing and referencing to the LGPLv3. That way everyone is happy.
I'm curious about the upgrade plan for Propel 1.3. It's probably coming out soon and it breaks API compatibility since it replaces Creole with PDO, among other things. More on API incompatibilities between 1.2 and 1.3: http://propel.phpdb.org/trac/wiki/Users/Documentation/1.3/Upgrading
Updated Spec URL: http://akahl.fedorapeople.org/php-pear-propel/php-pear-propel_runtime.spec Updated SRPM URL: http://akahl.fedorapeople.org/php-pear-propel/php-pear-propel_runtime-1.3.0-0.1.rc1.fc9.src.rpm Changes: - update to 1.3.0-rc1 - ownership of %%{pear_phpdir}/propel now claimed by both -runtime and -generator packages - dependencies update The license issue should now be fixed, license tag has changes to LGPLv3+ according to http://propel.phpdb.org/trac/wiki/Users/Introduction/License Jason and Hans, please confirm this.
Confirmed from our side. We've never specified a version & have updated our licensing to reflect the current version of LGPL. We intend to always use the latest version of the LGPL, but have indicated in the licensing that we are using v3 or later. While we recognize that there is some disagreement between Apache and FSF on the compatibility of LGPLv2 with Apache license, it is clear that everyone agrees in the compatibility of LGPL v3.
Indeed, there is no problem for LGPLv3 and Apache that I am aware of. LGPL is almost always compatible with things. :) Lifting FE-Legal.
Thanks spot. Still I'm missing someone for a review here..
OK, I'll take a look. First off, there are some issues with the Obsoletes: tags you have. Please see http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Renaming.2Freplacing_existing_packages for information on doing this properly. That will clear up all of the important rpmlint complaints: W: unversioned-explicit-obsoletes php-pear-propel-runtime W: unversioned-explicit-obsoletes php-pear-propel W: obsolete-not-provided php-pear-propel-runtime W: obsolete-not-provided php-pear-propel Also, please don't use Requires(hint):. This is just relying on undocumented behavior of rpm where it accepts any unrecognized parenthesized string after Requires: as a simple Requires:. It does not set up a soft dependency or anything of the sort.
Hi Jason, glad to see you back. Updated Spec URL: http://akahl.fedorapeople.org/php-pear-propel/php-pear-propel_runtime.spec Updated SRPM URL: http://akahl.fedorapeople.org/php-pear-propel/php-pear-propel_runtime-1.3.0-0.2.rc1.fc9.src.rpm Changes: - dropped Obsoletes - dropped php-pear-Log dependency, not really necessary Since I'm using Propel in real life projects at work, I know that PEAR/Log isn't really necessary - Propel defines an interface "BasicLogger" one can implement to use a custom logging facility.
You could include a dependency on the log package if you like; it's only 52K and doesn't have significant dependencies. In the end, that's up to you. Anyway, I think this is done now. * source files match upstream: 5957f1543b15d8be1246fe562587ed5d8904a66d2be71151f4db0dc7fe96fa1d propel_runtime-1.3.0RC1.tgz * package meets naming and versioning guidelines. * specfile is properly named, is cleanly written and uses macros consistently. * summary is OK. * description is OK. * dist tag is present. * build root is OK. * license field matches the actual license. * license is open source-compatible. * license text not included upstream. * latest version is being packaged. * BuildRequires are proper. * %clean is present. * package builds in mock (rawhide, x86_64). * package installs properly. * rpmlint has acceptable complaints. * final provides and requires are sane: php-pear(pear.phpdb.org/propel_runtime) = 1.3.0 php-pear-propel_runtime = 1.3.0-0.2.rc1.fc10 = /bin/sh /usr/bin/pear php >= 5.2.0 php-channel(pear.phpdb.org) php-dom php-pdo php-pear php-xml * %check is not present; no test suite upstream. * owns the directories it creates. * doesn't own any directories it shouldn't. * no duplicates in %files. * file permissions are appropriate. * scriptlets OK (pear module registration). * code, not content. APPROVED
New Package CVS Request ======================= Package Name: php-pear-propel_runtime Short Description: An Object Relational Mapping (ORM) framework for PHP5 Owners: akahl Branches: F-8 F-9 InitialCC: Cvsextras Commits: yes
cvs done.
All builds successful. Thank you guys!