Bug 266841

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!