Re: Updated maint-guide contents, question on style
Here are my responses.
On Mon, May 02, 2011 at 10:01:14PM +0100, Justin B Rye wrote:
> Osamu Aoki wrote:
> I suppose it's true that inserting "for each architecture" makes it
> clearer, but leave out the word "CPU" - the point I was trying to make
> is that "architecture" as defined in Policy isn't just a matter of
> hardware. After all, one of my machines dualboots i386/kfreebsd-i386
> and another can run either i386 or amd64...
> > | Line 10 describes the CPU architectures the binary package can be
> > | compiled for. We'll leave this as any because dpkg-gencontrol(1) will
> > | fill in the appropriate value for any machine this package gets compiled
> > | on.
> Since line 10 itself contains the field-name "Architecture:", we could
> if we wanted simply bypass the whole issue here and say:
> Line 10 describes the platforms the binary package can be
> But here are typofixes anyway:
> > + Line 10 describes the CPU architectures the binary package can be
> > + compiled for. This value are usually one of the following depending
> > + on the type of the binary package.
> > + <footnote><para>See
> > + <ulink url="http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Architecture">Debian Policy Manua 5.6.8 "Architecture"</ulink>
> > + for exact details.
> > + </para></footnote>
> > + * <literal>Architecture: any</literal>
> > + - The geneated binary package is architecture dependent one
> ^r is an
> > + usually from compiler languages.
> in a compiled language.
> > + * <literal>Architecture: all</literal>
> > + - The generated binary package is architecture independent one
> is an
> > + usually generated from interpreter languages or
> > + consisting of text or graphic data.
> usually consisting of text, images, or scripts in an interpreted language
> > +
> > + We leave line 10 as is since this is written in the C language.
> in C.
> > + dpkg-gencontrol(1) will fill in the appropriate CPU architecture
> > + value for any machine this source package gets compiled on.
I took out CPU altogether from 2 places and inserted text as you suggest.
> >> 4.4.1 ends by recommending "info make". Unfortunately these days
> >> that's in the non-free package make-doc.
> > I guess we can still install pre-GFDL version from old archive and
> > may be FREE. But that is not the worth the efforts. I can add following at the
> > end.
> > + <footnote><para>Since Debian considers the way the GFDL license is used for
> > + make-doc to be non-free based on DFSG, make-doc is in non-free archive.
> ^the ^the ^area.
> > + </para></footnote>
> > What do you think?
> Re-reading the end of 4.4.1 just makes me more worried:
> # You are probably confused now, but it will all be clear upon
> # examination of the rules file that dh_make gives us as a default. You
> # should also read info make for more information.
> Not only is info make hard to get hold of, but the claim that all will
> be clear seems overoptimistic, given that the example dh_make will
> offer consists of "%:\n\tdh $@". Point at the upstream Makefile,
> perhaps? (Though it seems cruel to expect people to work out how to
> write Makefiles just from reading them...)i
I will make some suffle and rewrite of 4.4.1.