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
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
