On 2 Feb 1998, Kirk Hilliard wrote:
> OK, here is my first bunch of question.
>
> 0. BTW, I built my packages in what I assume is the standard way. I
> ran deb-make, edited the files in debian/ and ran build. Should I
> be doing something differently? I am not quite comfortable with
> this level of automation, since I don't know what it all does yet.
deb-make/debstd are sort of getting phased out in favor of the debhelper
applets which provide greater control and granularity in the debian/rules
file. You don't have to use anything special however, it's all a matter
of personal preference (I use debhelper for my new stuff but have some
older debmake'd packages I haven't gotten around to updating).
> 1. Where does buildinfo.Debian come from, and does it really belong?
It's generated by debstd. It is small and is sometimes useful for
figuring out glitches with the major tools.
> OK, I assume that build (or dpkg-buildpackage or debstd or
> whatever) makes it, but I can't find this file mentioned in any of
> the documentation. If it is something that we are encouraged to
> include in the .deb, then why isn't it mentioned in the Policy or
> Packaging manual?
Mostly because debstd is the only thing that generates it and it is being
depreciated (by the original author).
> It lists the version of packages containing various development
> tools. But for my packages makeinfo is an important tool, and
> tetex-bin is not listed in buildinfo.Debian. Should I do something
> to include it?
No way I know to change it.
> 2. Do I need to do something special because I use makeinfo to build
> the packages?
>
> makeinfo is from tetex-bin which is a "Standard" package. Might it
> not be considered a standard development tool, and do I need to
> document its use somewhere?
makeinfo is hardly a program that is difficult to find or work with. If
you use more exotic tools it's nice to document somewhere what tools are
needed to build the package.
> 3. Why doesn't debstd gzip README.debian?
>
> Well, why doesn't debstd gzip README.debian? It does gzip the
> documentation mentioned on the "debstd" line of the debian/rules
> file.
Debstd uses a threshold size on what to compress and what not to. This
may or may not be considered a bug.
> 4. Should I edit the README to remove build information?
>
> Section 5.3 "Additional documentation" of the policy manual says:
>
> It is often a good idea to put text information files (READMEs,
> changelogs, and so forth) that come with the source package in
> /usr/doc/package in the binary package. However, you don't need to
> install the instructions for building and installing the package, of
> course!
>
> If the source package includes a README which contains some useful
> information, but which mostly talks about the build process, should
> I include it in its entirety, or may I edit out the build
> instructions?
Don't change upstream documentation like READMEs and such. If all they
detail is the compilation/installation process (like the INSTALL included
with many GNU packages) you can leave them out, otherwise include them
completely.
> 5. What happened to the "Section" and "Priority" fields?
>
> My debian/control file includes these lines:
>
> Section: doc
> Priority: optional
>
> but these fields are missing from control file of the .deb package.
> What happened?
dpkg-buildpackage -isp will include those values.
> 6. Why does `dpkg -I *.deb' say "new debian package"?
>
> When I run `dpkg -I *.deb' on my packages, the first line is:
>
> new debian package, version 2.0.
>
> Why? I didn't put anything in the control file to indicate that it
> is a new package, and there is a previous entry in the
> debian/changelog file.
That just specifys the type of the packaging format (the new 2.0 .deb
format as opposed to the old one).
> 7. Why do I get *_i386.changes when Architecture = all?
>
> My debian/control file includes the line:
>
> Architecture: all
>
> but after I build I get an emacs-lisp-intro_1.05-1_i386.changes
> file. Is this correct since I am building it on a i386 machine, or
> should it have been *_all.changes? (The package itself is
> *_all.deb.)
It's considered acceptable for the changelog to list an arch when the
package is _all. Mostly cosmetic, but since dinstall on master is the
only thing that cares, you don't need to worry.
> 8. Why is build complaining about "no utmp entry available"?
>
> When I build, I am told:
>
> no utmp entry available, using value of LOGNAME ("kirk") at
> /usr/lib/dpkg/controllib.pl line 16.
>
> but line 16 follows this line:
>
> if (!defined (getlogin ())) {
>
> and getlogin seems to work for me:
>
> $ perl -le 'print getlogin()'
> kirk
> $
>
> Does this have something to do with fakeroot?
Actually it is suspected to be a bug in libc6. It is however, completely
harmless when building your package, you don't need to worry about it.
--
Scott K. Ellis <[EMAIL PROTECTED]> http://www.gate.net/~storm/
