Spec URL: ftp://ftp.rexursive.com/pub/apr-api-docs/apr-api-docs.spec SRPM URL: ftp://ftp.rexursive.com/pub/apr-api-docs/apr-api-docs-1.2.8-1.fc7.src.rpm Description: The mission of the Apache Portable Runtime (APR) is to provide a free library of C data structures and routines, forming a system portability layer to as many operating systems as possible, including Unices, MS Win32, BeOS and OS/2. This package provides APR and APR-utils API documentation for developers.
This is a pretty small little doc package. Would it make more sense to just add it in to the main apr package? It would be easier to keep in sync then as well.
I did discuss this option with Joe (the APR/APU package lead maintainer) and he'd prefer to see the docs in a separate package. This way we can also put both APR and APU docs in one place. APR/APU have a very slow release cycle. I think the effort would not be great in maintaining this one, especially given that one only needs to bump and rebuild to keep up to date. I'm already maintaining a similar package - subversion-api-docs - and that has not been difficult.
ok. Just wanted to make sure you had checked to see... I will try and review this for you later tonight unless someone beats me to it.
Thanks, much appreciated! BTW, strangely enough, this documentation package _is_ architecture specific (i.e. it's not an oversight). That's because some constants in APR are actually different on different architectures, so people on multiarch need to have both set of docs. Just a heads up...
OK - Package meets naming and packaging guidelines OK - Spec file matches base package name. OK - Spec has consistant macro usage. OK - Meets Packaging Guidelines. OK - License (Apache) OK - License field in spec matches OK - License file included in package OK - Spec in American English OK - Spec is legible. OK - Sources match upstream md5sum: aa51ef5ee3063f456c07430aa20b0f49 doxygen.conf aa51ef5ee3063f456c07430aa20b0f49 doxygen.conf.1 210107e33110270ff1e20db6c1ac9dc8 LICENSE 210107e33110270ff1e20db6c1ac9dc8 LICENSE.1 OK - BuildRequires correct OK - Package has %defattr and permissions on files is good. See below - Package has a correct %clean section. OK - Package has correct buildroot OK - Package is code or permissible content. OK - Packages %doc files don't affect runtime. See below - Package has rm -rf RPM_BUILD_ROOT at top of %install OK - Package compiles and builds on at least one arch. OK - Package has no duplicate files in %files. OK - Package doesn't own any directories other packages own. OK - Package owns all the directories it creates. OK - No rpmlint output. OK - final provides and requires are sane SHOULD Items: OK - Should build in mock. OK - Should build on all supported archs OK - Should function as described. OK - Should have dist tag Issues: 1. Why the rm -rf %{name}-%{version} in clean? 2. Your Source1 has a typo in it: Source1: http://svn.apache.org/repos/asf/apr/apr/tags/%{version}}/LICENSE Note the }} there. 3. rpmlint, or pal says: W: apr-api-docs mixed-use-of-spaces-and-tabs (spaces: line 9, tab: line 1) Fix if you get a chance. E: apr-api-docs no-binary As you say, this can be ignored.
Thanks for that. I will address and report back.
New spec and SRPM now available: ftp://ftp.rexursive.com/pub/apr-api-docs/apr-api-docs.spec ftp://ftp.rexursive.com/pub/apr-api-docs/apr-api-docs-1.2.8-2.fc7.src.rpm Issues addressed: 1. Without this, rpmbuild --clean won't remove BUILD/%{name}-%{version} directory. I'm guessing it's because we don't have a tarball and we don't run %setup macro. 2. Thanks! Should be fixed now. 3. Sorry :-(. Hangover from subversion-api-docs, which I now also fixed.
Per discussion in private mail: Putting the docs in a noarch.rpm was really the main reason for making this a separate source package. As shipped they are arch-specific because they include macro values - those values are of course implementation details. I don't think it's a big deal to simply make the package noarch and ignore the fact that the generated docs will document macro values specific to one arch. Ideally the docs are munged to be genuinely arch-neutral.
New spec and SRPM are now available: ftp://ftp.rexursive.com/pub/apr-api-docs/apr-api-docs.spec ftp://ftp.rexursive.com/pub/apr-api-docs/apr-api-docs-1.2.8-3.fc7.src.rpm They include two major changes: - the built package is noarch - build dependency on apr-util-devel is not version specific, since APR and APU can be at different versions at the same time Obviously, this package has been done on F7. For it to work on devel, it will be bumped to 1.2.9.
The 3 issues I saw are all ok. Not sure I like a noarch package that produces different results depending on what host it's built on. I think the buildsys allocates whatever builder is idle, so you could well get different arches on different runs. ;( What are the macros that are arch specific? Would it be possible to munge them (as suggested in comment #8)?
This stuff: http://apr.apache.org/docs/apr/1.2/group__apr__platform.html Essentially, it explains what a particular macro/typedef is going to be on a particular platform. As you can see in the above URL, the values are i686 specific, because they've been generated on my notebook. If someone else generated those, they would look different. Confusing, just like the results we get with a random Fedora builder - that's why my initial package was arch specific. However, I do get Joe's point - although those things are there in the docs, it is not something APR API users should use or rely on anyway, as this would defeat the purpose of APR. If you have a good idea as to how to munge those, let me know. We can also just insert a comment up the top saying that API users should not rely on implementation details, as they may vary from platform to platform.
Ping...
Sorry for the long delay here. :( I think a comment at the top that the details may vary from platform to platform might suffice here. Could you add such a comment? Perhaps upstream could even add such a note?
No worries. I always forget that it is summer in the northern hemisphere right now and that people may be on holidays. Adding it to the spec file (sed/perl) would be trivial and probably the only thing we can do until the next release of APR/APU. I can also ask upstream, as I think it makes sense to let people know that what they are seeing should not be relied upon.
Well, I've just been really busy, not on holiday. However, next week I will be on holiday. ;) Can you post an updated package with the warning comment, and I think then this package will be ready for approval.
I should have that ready tomorrow. BTW, so far upstream feedback has been positive.
Now available: ftp://ftp.rexursive.com/pub/apr-api-docs/apr-api-docs.spec ftp://ftp.rexursive.com/pub/apr-api-docs/apr-api-docs-1.2.8-4.fc7.src.rpm We now have that platform specific warning. I also included APU headers, which I missed previously and fixed the years in the changelog (we are in fact in 2007 :-).
The package in comment #17 looks good to me. This package is APPROVED. Don't forget to close this once it's been imported and built.
Thanks! Shall do.
New Package CVS Request ======================= Package Name: apr-api-docs Short Description: Apache Portable Runtime API documentation Owners: bojan Branches: F-7 InitialCC:
cvs done.
Thanks everyone involved! This bug will now be closed.
apr-api-docs-1.2.8-4.fc7 has been pushed to the Fedora 7 testing repository. If problems still persist, please make note of it in this bug report.
apr-api-docs-1.2.8-4.fc7 has been pushed to the Fedora 7 stable repository. If problems still persist, please make note of it in this bug report.