Bug 244951 - Review Request: apr-api-docs - Apache Portable Runtime API documentation
Review Request: apr-api-docs - Apache Portable Runtime API documentation
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Kevin Fenzi
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2007-06-19 21:42 EDT by Bojan Smojver
Modified: 2007-11-30 17:12 EST (History)
4 users (show)

See Also:
Fixed In Version: 1.2.8-4.fc7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-07-25 01:21:22 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
kevin: fedora‑review+
kevin: fedora‑cvs+

Attachments (Terms of Use)

  None (edit)
Description Bojan Smojver 2007-06-19 21:42:04 EDT
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.
Comment 1 Kevin Fenzi 2007-06-21 00:13:55 EDT
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. 

Comment 2 Bojan Smojver 2007-06-21 17:24:53 EDT
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.
Comment 3 Kevin Fenzi 2007-06-21 18:59:38 EDT
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. 
Comment 4 Bojan Smojver 2007-06-21 19:11:19 EDT
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...
Comment 5 Kevin Fenzi 2007-06-21 23:20:17 EDT
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


OK - Should build in mock.
OK - Should build on all supported archs
OK - Should function as described.
OK - Should have dist tag


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.
Comment 6 Bojan Smojver 2007-06-21 23:55:45 EDT
Thanks for that. I will address and report back.
Comment 7 Bojan Smojver 2007-06-22 00:36:55 EDT
New spec and SRPM now available:


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.
Comment 8 Joe Orton 2007-06-25 18:14:51 EDT
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.
Comment 9 Bojan Smojver 2007-06-25 19:02:16 EDT
New spec and SRPM are now available:


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.
Comment 10 Kevin Fenzi 2007-06-25 22:24:16 EDT
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)?
Comment 11 Bojan Smojver 2007-06-25 22:39:51 EDT
This stuff:


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.
Comment 12 Bojan Smojver 2007-07-11 20:17:42 EDT
Comment 13 Kevin Fenzi 2007-07-17 23:01:21 EDT
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?

Comment 14 Bojan Smojver 2007-07-18 01:01:19 EDT
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.
Comment 15 Kevin Fenzi 2007-07-18 01:40:47 EDT
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. 
Comment 16 Bojan Smojver 2007-07-18 03:51:08 EDT
I should have that ready tomorrow.

BTW, so far upstream feedback has been positive.
Comment 17 Bojan Smojver 2007-07-18 20:44:56 EDT
Now available:


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 :-).
Comment 18 Kevin Fenzi 2007-07-19 23:09:02 EDT
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. 
Comment 19 Bojan Smojver 2007-07-19 23:22:45 EDT
Thanks! Shall do.
Comment 20 Bojan Smojver 2007-07-19 23:46:33 EDT
New Package CVS Request
Package Name: apr-api-docs
Short Description: Apache Portable Runtime API documentation
Owners: bojan@rexursive.com
Branches: F-7
Comment 21 Kevin Fenzi 2007-07-20 00:22:14 EDT
cvs done.
Comment 22 Bojan Smojver 2007-07-20 01:03:39 EDT
Thanks everyone involved! This bug will now be closed.
Comment 23 Fedora Update System 2007-07-20 15:30:29 EDT
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.
Comment 24 Fedora Update System 2007-07-25 01:21:11 EDT
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.

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