Bug 266841 - Review Request: php-pear-propel_runtime - An Object Relational Mapping (ORM) framework for PHP5
Summary: Review Request: php-pear-propel_runtime - An Object Relational Mapping (ORM) ...
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Jason Tibbitts
QA Contact: Fedora Extras Quality Assurance
: 266801 266821 (view as bug list)
Depends On: 266941
Blocks: 351441
TreeView+ depends on / blocked
Reported: 2007-08-30 12:23 UTC by Alexander Kahl
Modified: 2008-07-08 20:24 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2008-07-08 20:24:45 UTC
Type: ---
tibbs: fedora-review+
kevin: fedora-cvs+

Attachments (Terms of Use)

Description Alexander Kahl 2007-08-30 12:23:32 UTC
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.

Comment 2 Alexander Kahl 2007-10-11 15:47:30 UTC
Updated Spec URL:
Updated SRPM URL:

- merged in all metapackages (thus removed bug dependencies)
- consequently adapted macros for all shell operations
- s/%{buildroot}/$RPM_BUILD_ROOT/

Comment 3 Alexander Kahl 2007-10-11 15:50:47 UTC
*** Bug 266821 has been marked as a duplicate of this bug. ***

Comment 4 Alexander Kahl 2007-10-11 15:51:16 UTC
*** Bug 266801 has been marked as a duplicate of this bug. ***

Comment 5 Alexander Kahl 2007-10-18 12:52:28 UTC
Updated Spec URL:
Updated SRPM URL:

- made runtime subpackage the main package instead
- fixed package ownerships
- fixed template script execution permissions

Comment 6 Jason Tibbitts 2007-10-23 23:35:22 UTC
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.

Comment 7 Jason Tibbitts 2007-11-19 03:25:17 UTC
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.

Comment 8 Alexander Kahl 2007-11-24 14:09:24 UTC
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?

Comment 9 Alexander Kahl 2007-12-04 09:52:02 UTC
ping Jason

Comment 10 Jason Tibbitts 2007-12-20 06:26:03 UTC
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.

Comment 11 Jason Tibbitts 2008-01-21 05:12:40 UTC
So, what's going to happen with this package?  Did you decide whether or not to
split it into two?

Comment 12 Alexander Kahl 2008-02-15 21:02:38 UTC
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

Updated Spec URL:
Updated SRPM URL:

Comment 13 Alexander Kahl 2008-03-25 21:14:10 UTC
ping jason

Comment 14 Jason Tibbitts 2008-03-25 21:27:57 UTC
Jason is not really doing any reviews as of late.  You kind of missed the window
where I had free time.

Comment 15 Jason Tibbitts 2008-04-05 03:55:49 UTC
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.

Comment 16 Alexander Kahl 2008-04-05 10:24:47 UTC
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
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..?

Comment 17 Hans Lellelid 2008-04-05 12:37:26 UTC
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

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.

Comment 18 Xavier Bachelot 2008-04-24 13:00:20 UTC
hmm, it seems both the spec and the srpm have disappeared...

Comment 19 Brad Walker 2008-04-24 13:08:40 UTC
Xavier, the links in comment #12 WFM.

Comment 20 Xavier Bachelot 2008-04-24 13:14:18 UTC
oh, sorry, I didn't catch the change, the URL from comment #12 works for me too,
indeed... Sorry for the noise.

Comment 21 Tom "spot" Callaway 2008-05-12 20:16:22 UTC
(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.

Comment 22 Hans Lellelid 2008-05-12 20:46:18 UTC
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.

Comment 23 Brad Walker 2008-05-22 03:32:45 UTC
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

More on API incompatibilities between 1.2 and 1.3:

Comment 24 Alexander Kahl 2008-06-01 13:32:38 UTC
Updated Spec URL:
Updated SRPM URL:

- 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.

Comment 25 Hans Lellelid 2008-06-02 00:10:42 UTC
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.

Comment 26 Tom "spot" Callaway 2008-06-04 21:32:01 UTC
Indeed, there is no problem for LGPLv3 and Apache that I am aware of. LGPL is
almost always compatible with things. :) Lifting FE-Legal.

Comment 27 Alexander Kahl 2008-07-01 20:38:26 UTC
Thanks spot.
Still I'm missing someone for a review here..

Comment 28 Jason Tibbitts 2008-07-03 01:42:19 UTC
OK, I'll take a look.

First off, there are some issues with the Obsoletes: tags you have.  Please see 
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.

Comment 29 Alexander Kahl 2008-07-03 08:17:32 UTC
Hi Jason, glad to see you back.

Updated Spec URL:
Updated SRPM URL:

- 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.

Comment 30 Jason Tibbitts 2008-07-04 02:57:19 UTC
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:
* 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
   php >= 5.2.0

* %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.


Comment 31 Alexander Kahl 2008-07-06 12:01:26 UTC
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
Cvsextras Commits: yes

Comment 32 Kevin Fenzi 2008-07-07 02:05:53 UTC
cvs done.

Comment 33 Alexander Kahl 2008-07-08 20:24:45 UTC
All builds successful. Thank you guys!

Note You need to log in before you can comment on or make changes to this bug.