Bug 228296

- While the license of pylirc in the sources and PKG-INFO is said to be LGPL, it
links with liblirc_client which is unconditionally GPL AFAICT -> the license of
this package when distributed should be GPL too.  LGPL allows that (see its
chapter 3 - references to LGPL should be replaced by GPL when doing that).

- Add "Provides: pylirc = %{version}-%{release}" for upstream compatibility and
because "python-lirc" is substantially different from "pylirc"?

- Include PKG-INFO in %doc?

Thanks for this quick and valuable feedback :-) lirc-0.0.5-2.fc6 available :

* Thu Feb  8 2007 Matthias Saou <http://freshrpms.net/> 0.0.5-2
- Change License from GPL to LGPL as our package links with lirc which is GPL.
- Add pylirc (original name) virtual provides.
- Include the API doc and both examples from the website.

Oh, I added PKG-INFO to the %doc (is it really useful?), but also took the time
to add the only doc really available : the few pages on the website.

Adding the extra docs is a nice idea, however they currently suffer from
genericish SourceX file names.  Prefix them by %{name}-* (in SRPM, not when
installed)?

About licensing, LGPL section 3 says: "You may opt to apply the terms of the
ordinary GNU General Public License instead of this License to a given copy of
the Library.  To do this, you must alter all the notices that refer to this
License, so that they refer to the ordinary GNU General Public License, version
2, instead of to this License."

I'm not 100% sure what that means in practical terms, but it sounds to me as if
the license info should be changed not only in the License tag, but also the C
source file as well as PKG-INFO, and possibly the newly added changes.  Or at
least add a note somewhere prominent about the change (separate file installed
as %doc or something).  What do you think?

I don't see where "generic" file names would be a problem, as long as they're
managed in CVS and not uploaded as sources. These will be managed in CVS.

About the LGPL -> GPL change, I'd change it in the PKG-INFO that will go with
the binary rpms, and that's it. No change to the C file, since the source rpm
can be considered LGPL, but our binary builds against lirc will have to be GPL.
Comments in the spec file will detail this a little. Would that be okay?

Generic filenames have nothing to do with the Fedora CVS nor the lookaside
cache.  Both manage them just fine (lookaside cache using md5sums in dir names
for different revisions of the same file).  But when 'rpm -i'ing a bunch of
source rpms locally it may very well become a problem.

Adding specfile comments about the licensing stuff won't be visible to users of
this package, therefore a seprately installed file included in the binary
package detailing what was done is clearly a better solution in my opinion.

Oh, I get it, you mean people still using a single %_sourcedir... hmmm... this
is no longer relevant with mach/mock, and it makes the build simpler if you
don't have to change the file names when installing them... do you *really* want
me to change the file names?

As for the license, we re-license the binary package under the GPL since it's
linked to a GPL library. We aren't required to add something like "used to be
LGPL", and I doubt a single end-user will actually care about the change, so as
long as we comply with the terms and make the info available somewhere (in the
source rpm), I would think it's fine.

(In reply to comment #6)
> do you *really* want me to change the file names?

Yes.

> We aren't required to add something like "used to be
> LGPL", and I doubt a single end-user will actually care about the change,

Shrug, even if not required, if it's worth it to spend much more time explaining
why not add a user visible file noting why the license is changed than adding
the file would have taken, and the possible questions about the change will flow
your way as the maintainer later on too, I guess I shouldn't care.  It's not
only about end users, packagers of apps requiring this package will have to
notice the change and take it into account in their packages as well.

Conditionally approved with the assumption that the source filenames get a
%{name}-* or something like that prefix before the first build.

http://ftp.es6.freshrpms.net/tmp/extras/python-lirc/python-lirc.spec
http://ftp.es6.freshrpms.net/tmp/extras/python-lirc/python-lirc-0.0.5-3.src.rpm

* Thu Mar  1 2007 Matthias Saou <http://freshrpms.net/> 0.0.5-3
- Prefix all our own documentation source files.
- Include a README about our license changes and added docs.

This should basically include all of what you suggested. Please confirm before I
import the package ;-)

Looks like an improvement to me, thanks.  However, there's breakage - Both
python-lirc-API and python-lirc-README are Source1, and Source4 doesn't exist. 
Approval still stands, I'm sure you'll fix those before the first build :)

D'oh! Typical last second changes which... break. Good, that's fixed, and I just
tested a rebuild & install. All seems fine. I'll go ahead and request CVS
branches to be created now, thanks!

http://fedoraproject.org/wiki/CVSAdminProcedure
In the future, please follow the CVS procedure here.

New Package CVS Request
=======================
Package Name: python-lirc
Short Description: Linux Infrared Remote Control python module
Owners: matthias
Branches: FC-5, FC-6, EL-4, EL-5
InitialCC: 

Sorry Warren, I didn't know there was now a better documented way to make those
CVS requests. Now I do. Ville : I'm pretty sure some people will be interested
in running their HTPC on "stable" distros like RHEL... are you planning on
getting lirc into EPEL?

I am one of those people, but can't tell for sure yet - one big factor for me
regarding various multimedia related packages is whether RHEL5/CentOS5 kernels
will include DVB drivers (or if not, whether I feel like packaging them myself
or can get them sanely packaged from somewhere else) and if I get past this
point, how well I can get my VDR HTPC/PVR to run on it.  If this turns out to be
too much work for my taste, it's unlikely that I would be interested in
maintaining LIRC in EPEL.