[Clfs-dev] r7105

[Alexander E. Patrakov]

Randy McMurchy wrote:
> Alexander E. Patrakov wrote these words on 09/11/07 08:04 CST:
>
>   
>> OK. Now imagine the following situation: someone wants to create a 
>> Debian package with the LFS book. Debian policy requires that all HTML 
>> and PDF files are rebuilt from XML source in this case.
>>     
>
> Pardon my ignorance to Debian procedures, but what exactly does
> "create a Debian package" mean?

For Debian Developers, this means:

1) (Re)package the original source files into a tar.gz archive, rename 
it according to the Debian requirements (something like 
lfs-book_6.3+r7105.orig.tar.gz)

2) Patch the sources as needed to resolve bugs, etc.

3) Create a "debian" directory with the files that are used for creating 
*.deb files from the above-mentioned source, plus various 
Debian-specific mandatory documentation such as a packaging changelog. 
The following set of files is typical: 
debian/{changelog,compat,control,copyright,rules}. debian/rules is just 
a Makefile (with "#!/usr/bin/make -f" at the top and the executable bit 
set) with several mandatory targets (such as "binary", which builds the 
sources and packs the result into the deb packages). debian/control, 
most importantly, lists the build-time and run-time dependencies.

4) Create a diff.gz between the freshly unpacked contents of orig.tar.gz 
and the result of steps (2)+(3) above. I.e., the patch would contain 
bugfixes plus the whole "debian" directory.

5) Create the dsc file from the debian/control file (using the 
"dpkg-buildpackage" tool). This file contains build-time dependencies, 
package version, the desired architectures, and MD5 sums of orig.tar.gz 
and diff.gz files, all signed with GPG.

6) Upload the dsc, orig.tar.gz and diff.gz files to a buildd (a machine 
that runs a "build daemon"). The daemon will automatically verify your 
signature, create a chroot, populate it with the build-time dependencies 
of your package, unpack it, apply the diff, and run "debian/rules 
binary". The resulting deb files are then automatically placed into the 
archive.


> And so I can properly evaluate
> the situation as it pertains to going back to system-installed
> XSL Stylesheets, why does "Debian policy" affect anything we do
> in (B)LFS?
>   

Strictly speaking, it doesn't. However, it would be nice if LFS 
cooperates a bit more with packagers by making their job easier.


>> If the LFS book 
>> relies on the external DocBook XSL setup of a certain version, I see no 
>> way to do it, except by reverting the switch to the external copy of 
>> DocBook XSL stylesheets (which is as bad as any other reversion of 
>> upstream changes) or changing the stylesheet version to "current" (which 
>> is going to break PDF - even worse).
>>     
>
> How have you been doing it for the last few *years* (up until just
> a month or so ago)?

I was not a Debian user then.

>  Why wasn't this an issue for the many years
> we used external XSL stylesheets?
>   

Because nobody attempted to create a package for other distros.

>> The problem is that old versions of DocBook XSL are simply not available 
>> as Debian packages, so one cannot build-depend on them without 
>> immediately getting a release-critical bug report.
>>     
>
> Again, why do we care what is available as a Debian package? And
> why couldn't one just install whatever version of stylesheets that
> makes Debian happy and create a 'current' symlink pointing at it.
>   

Because the buildd won't do it for you.

>> Maybe it makes sense, in the case of switching to the released version 
>> of DocBook XSL, to adopt a solution from argouml:
>>
>>  * depend on a known (not "current") version of DocBook XSL
>>  * don't keep a copy of DocBook XSL in SVN (but maybe add to tarballs)
>>  * add a Makefile target for downloading the correct version of DocBook XSL
>>  * make it easy to use this private just-downloaded copy of stylesheets 
>> instead of the (possibly non-existent) system-wide installation
>>     
>
> I'm lost here. I don't think I fully grasp what the problem is,
>   

Most distro packages are autobuilt according to buildscripts. One cannot 
specify a dependency on something (e.g., old version of docbook-xsl) 
which is not packaged.

> and why we'd need to worry about any of this.

Nothing beyond "it would be nice to cooperate with packagers".

> We never had to worry
> about any of it before, and there was never an issue that I knew of
> (or perhaps there was, and it was never mentioned?).
>   

You are right - the issue always existed but was never mentioned.

-- 
Alexander E. Patrakov