Rudder

Not sure it will be possible to generate PDF on SLES...

Matthieu CERDA wrote:

Why would we want to build the PDF on SLES when we have tons of decent OSes to do it ? Would'nt it be more intelligent to build the PDF on the CI itself, and then just wget/curl it from the CI at build time ?

Because the community couldn't wget/curl this PDF and a build could be made by someone else than Normation.

I think matthieu don't that the user would have to curl/wget it from normation, but that we would build it on the CI then add it to the package. at least download it before making the package.

Nicolas PERRON wrote:

Jonathan CLARKE wrote:

I think that there is no point trying to rebuild the PDF on each and every platform. This won't change anything, unlike code which may be linked to different libraries, versions, etc, a PDF is a PDF.

The best approach here is clearly to have one single "build" of the documentation, then re-use the results for all packages (on a related note, this is what we would like to converge towards for the Java WARs aswell, since they too are platform-independant. This approach has the added benefit of making each package build shorter (less to do).

In principle, although not necessarily in details, I agree with Matthieu's suggestion, that we build the PDF and HTML docs once, then get the packaging to get these files. I'm thinking that the SOURCES/Makefile would be most appropriate to get them, at the same time as we get the rudder-sources tarball.

Nicolas, I don't understand your comment about the community not being able to download them. These files are already available on rudder-project.org/rudder-doc-X.Y/ where X.Y is the major version number. Just take them from there.

Ok, this was one of my proposition but I think that we didn't understand each other.

The problem is that if we build somthing with SOURCES/Makefile, we don't have anything to control that we have the needed packages unlike debian/control or SPECS/*.spec.

I suppose addind comments into the Makefile would suffice.

No, you've misunderstood me. I am absolutely not suggesting building anything in SOURCES/Makefile. That is just wrong.

What I am suggesting is that the build happens only once ever, and that the results are uploaded somewhere where SOURCES/Makefile can just download them. So, in summary:

1. A job that builds the docs and publishes them. We already have that, the docs are available on http://www.rudder-project.org/rudder-doc-X.Y/.
2. Adding to SOURCES/Makefile for the package that needs the docs, just a curl/wget or two to get the pre-built docs.

Jonathan CLARKE wrote:

Nicolas PERRON wrote:

Jonathan CLARKE wrote:

I think that there is no point trying to rebuild the PDF on each and every platform. This won't change anything, unlike code which may be linked to different libraries, versions, etc, a PDF is a PDF.

The best approach here is clearly to have one single "build" of the documentation, then re-use the results for all packages (on a related note, this is what we would like to converge towards for the Java WARs aswell, since they too are platform-independant. This approach has the added benefit of making each package build shorter (less to do).

In principle, although not necessarily in details, I agree with Matthieu's suggestion, that we build the PDF and HTML docs once, then get the packaging to get these files. I'm thinking that the SOURCES/Makefile would be most appropriate to get them, at the same time as we get the rudder-sources tarball.

Nicolas, I don't understand your comment about the community not being able to download them. These files are already available on rudder-project.org/rudder-doc-X.Y/ where X.Y is the major version number. Just take them from there.

Ok, this was one of my proposition but I think that we didn't understand each other.

The problem is that if we build somthing with SOURCES/Makefile, we don't have anything to control that we have the needed packages unlike debian/control or SPECS/*.spec.

I suppose addind comments into the Makefile would suffice.

No, you've misunderstood me. I am absolutely not suggesting building anything in SOURCES/Makefile. That is just wrong.

What I am suggesting is that the build happens only once ever, and that the results are uploaded somewhere where SOURCES/Makefile can just download them. So, in summary:

1. A job that builds the docs and publishes them. We already have that, the docs are available on http://www.rudder-project.org/rudder-doc-X.Y/.
2. Adding to SOURCES/Makefile for the package that needs the docs, just a curl/wget or two to get the pre-built docs.

Ok. I was starting by the idea of building everything from source. Ÿou're right, this is smarter and the packages will continue to be buildable for external packager.

Applied in changeset packages:commit:c5f20fac1d23f141f293950f8f87cc68de633d17.

This is strange, on Debian the PDF file is now rudder-doc.pdf.gz:

nperron@rudder-snapshot:/usr/share/doc/rudder$ ls -lh /usr/share/doc/rudder/pdf/
total 1.4M
-rw-r--r-- 1 root root 1.4M Aug 30 15:12 rudder-doc.pdf.gz

nperron@rudder-snapshot:/usr/share/doc/rudder$ ls -lh /usr/share/doc/rudder/html/
total 556K
-rw-r--r-- 1 root root 144K Aug 30 15:12 agent_workflow.png
-rw-r--r-- 1 root root  24K Aug 30 15:11 concepts.png
-rw-r--r-- 1 root root  54K Aug 30 15:12 data_workflow.png
-rw-r--r-- 1 root root  38K Aug 30 15:12 generate_policy_workflow.png
drwxr-xr-x 4 root root 4.0K Aug 30 16:04 images
-rw-r--r-- 1 root root  19K Aug 30 15:12 logoRudder.jpg
-rw-r--r-- 1 root root  26K Aug 30 15:11 packages.png
-rw-r--r-- 1 root root   23 Feb 26  2012 robots.txt
-rw-r--r-- 1 root root 223K Aug 30 15:12 rudder-doc.html
lrwxrwxrwx 1 root root   24 Aug 30 16:04 rudder-doc.pdf.gz -> ../pdf/rudder-doc.pdf.gz

Argh... this is due to dh_compress: dh_compress - compress files and fix symlinks in package build directories

I'll open a new bug for this.

Nicolas PERRON wrote:

Argh... this is due to dh_compress: dh_compress - compress files and fix symlinks in package build directories

I'll open a new bug for this.

I have opened #3895 for this issue.