[OpenSER-Devel] SF.net SVN: openser: [2950] trunk/scripts

[Dan Pascu]

On Monday 22 October 2007, Henning Westerholt wrote:
> This happens already with the README files on my machine. My
> docbook2txt uses a different line length, so many files are wrapped
> differently, and i must fix them before commiting..

Which is a real pain and unnecessary work to do just to avoid a 
dependency, which nowadays one can just "apt-get install xyz" or 
"apt-get build-dep openser" or some other distro's equivalent.

> > 2. Assume you want to build a debian package, but need an altered db
> > schema. You use dpatch to create a patch that modifies the xml schema
> > and build the package. But now, the generated files will also be
> > different and after a make proper they won't be returned to the
> > original state which means that the debian diff will be broken if you
> > build it again. Now one could include the modifications to the
> > generated files in the debian patch as well (but this is pretty much
> > an ugly hack as it assumes that the generated files and their
> > counterparts resulted from patching are identical). One shouldn't
> > patch files that are generated as a result of the build process. If
> > the generation tool changes the generated output at all, the patch
> > will no longer be able to deapply and you will be required to remake
> > the debian patch from scratch. At any rate maintainability of this
> > situation is very poor and problematic.
>
> I would prefer to not include the autogenerated files in the
> distribution. If we need them because we don't like this depencies,
> then we should stop building them automagically. This would also be
> consistent with the README files case.
>
> If nobody object, i'll remove the autobuilding from the debian packages
> later. 

I would very much prefer to remove them from svn and build them 
automatically. If we keep them around and do not build them, then we need 
to patch the generated files as well, not only the xml schemas when we 
make custom modifications, which is again an unnecessary pain.

Even more considering that we already need bison, flex, make, gcc, what 
difference does it make to have xsltproc added to the dependencies, 
considering that everybody nowadays runs a distro which has already 
packed it for you, given that is such a common tool.

> For the "normal" make there already not build them. 

For the moment I found the solution of building the schemas and removing 
them when building/cleaning the debian package. This avoids the need to 
patch the generated files, but is still not optimal as it requires that 
the orig.tar.gz is different from the officially shipped one (the 
generated db schemas are removed, which is exactly what I'm saying would 
solve this situation with the minimum of work/effort).

-- 
Dan