Bug 196281 (php-manual-en)

(In reply to comment #0)
> W: php-manual-en invalid-license Open Publication License v1.0

Just "OPL" would be better?

> - Arguably the package should be php-manual-en-us, since in theory there
> might be an en_GB manual at some point, but I wonder whether this is going
> too far with the whole abstraction

Some other languages really requires the xx_YY naming... The package could 
contain php manuals from other languages too, don't you think? A source 
package could crate some packages, one for each language.

About the en vs. en-us, I think you should follow upstream on this. So 
only 'en' is IMO the right thing.

> - the Source URL is not really right for two reasons:
> 
> a) it has to have a silly /mirror/rubbish/junk on the end
> b) it doesn't include the version in it
> 
> but this is an upstream problem.

You should download and get the exact URL, for example:
http://us2.php.net/distributions/manual/php_manual_en.tar.gz

> > W: php-manual-en invalid-license Open Publication License v1.0
> Just "OPL" would be better?

It doesn't include a version. We really ought to specify a version if the
package specifies one, because otherwise if there's (say) an OPL v3 in future
with different terms, we would be misleading users by implying they could
distribute it under the terms of OPL v3 whereas the authors might have only
specified OPL v1. We should respect the author's license. Note for example that
recent Core "php" packages have started explicitly mentioning license version.

That said, "OPL v1.0" is fine by me, but I'm pretty sure rpmlint doesn't know
that either and it's less descriptive.
 
> > - Arguably the package should be php-manual-en-us, since in theory there
> > might be an en_GB manual at some point, but I wonder whether this is going
> > too far with the whole abstraction
> Some other languages really requires the xx_YY naming... 

That's ok, they can name it "php-manual-pt-br" or whatever as necessary.

I could maybe make the current package Provide php-manual-en-us, for forward
compatibility in case it gets split in future. That would make sense.

> The package could contain php manuals from other languages too, don't you 
> think? 

Yes, but see linked thread: I don't want the responsibility of maintaining them.
Also if I included every language supplied by PHP then the source RPM would be
really huge.
Additionally in future it's possible that not all languages would get updated at
the same time, so it could in theory mean pushing a big update SRPM even though
many sources are unchanged.

> You should download and get the exact URL, for example:
> http://us2.php.net/distributions/manual/php_manual_en.tar.gz

Thanks, I didn't pick up on that direct URL.

Updated files:

Spec URL: http://www.timj.co.uk/linux/specs/php-manual-en.spec
SRPM URL: http://www.timj.co.uk/linux/srpms/php-manual-en-20060527-2.src.rpm

Use %{_defaultdocdir} instead of %{_datadir}/doc

Use %{_defaultdocdir}/php-manual instead of %{_defaultdocdir}/php-manual/en in
your %files section.

(In reply to comment #3)

> Use %{_defaultdocdir}/php-manual instead of %{_defaultdocdir}/php-manual/en in
> your %files section.

How does this take account of the i18n issues raised in the linked thread?

There is no clear hierachry of directory ownership of the
%{_defaultdocdir}/php-manual so all packages that use this directory should own
this directory.

Unless there is some other issue I am missing?  I'm not sure what you are
referring to when you say "linked thread".

(In reply to comment #5)

Are you trying to say I should *add* a %dir %{_defaultdocdir}/php-manual? If so,
yep, good call.

What you implied was that the docs should go in %{_defaultdocdir}/php-manual
instead of %{_defaultdocdir}/php-manual/en , which seems to not cater for
further internationalisation (e.g. future packages providing ....php-manual/fr
for example.

"Linked thread" refers to the thread mentioned in the bug description, namely:

https://www.redhat.com/archives/fedora-extras-list/2006-May/msg00237.html

Yes this is what I'm trying to say. You can add the %dir, or I think just saying
%{_defaultdocdir}/php-manual in the %files section will accomplish the same
thing, either way you want to code it is fine.

I think all this is sorted.

- rpmlint is quiet
- updated to latest ver
- docdir ownership is good

Spec URL: http://www.timj.co.uk/linux/specs/php-manual-en.spec
SRPM URL: http://www.timj.co.uk/linux/srpms/php-manual-en-20060725-1.src.rpm

-rpmlint output clean
-package named according to Package Naming Guidelines
-spec file name matches package %{name}
-package licensed with open-source compatible license

O I could not find the license file in the package or on the web site.  Please
let me know where I can find the upstream license

-license file not included in %doc
-spec file written in American English
-spec file legible
-source matches upstream
a8ef43e9ff1da2ce18df90e67fc5758f  php_manual_en.tar.gz
-package successfully compiles and builds on FC-5 x86_64
-package does not need any BuildRequires
-spec file does not contain any locales
-package does not contain any shared libraries
-package is not relocatable
-package owns all directories it creates
-package does not contain any duplicate files in %files
-file permissions set properly
-package contains proper %clean section
-macro usage is consistent
-package contains permissible content
-use of -doc subpackage does not make sense in this context since package is
already a doc package
-package does not include %doc
-package does not include header files or static libraries
-package does not use pkgconfig
-package does not contain any .so files
-package does not build a -devel subpackage
-package does not contain any .la files
-package is not a GUI needing a .desktop file
-package does not own files or directories owned by other packages


==== MUST ====
- Explain where documentation is licensed

==== SHOULD ====
- include a license file and place it in %doc

copyright.html describes the distribution license
opl.license.html and linked pages are the license itself

I'd be tempted to symlink these into %{doc}, except that they are generated HTML
pages that would have broken links out of context.

How does creating a "placeholder" LICENSE file in %{doc} that says "For
licensing information please see %{defaultdocdir}/php-manual/en/copyright.html"
sound?

Actually, this is good enough.  I just needed to know where it was located in
order to complete the review.  You may want to add a comment in the spec file
indicating where the license is located, but not necessary.

Approved as is.

Imported & built - job #14355. Thanks for all the input!