Re: My first packages -- some questions.
Hi,
>>"Kirk" == Kirk Hilliard <kirk@ghoti.com> writes:
Kirk> 0. BTW, I built my packages in what I assume is the standard
Kirk> way. I ran deb-make, edited the files in debian/ and ran build.
Kirk> Should I be doing something differently? I am not quite
Kirk> comfortable with this level of automation, since I don't know
Kirk> what it all does yet.
You and me both. I never have used debmake/deb-helper and
friends; I checked them out as they came out, and have made a
persona; decision not to use them.
My preferred method is to look at other debian/rules files and
program by example; it has a slightly steeper learning curve, I
guess, but at least I understad what is going on.
I'll be willing to mail you a tar file of several debian/rules
files for perusal.
Kirk> 1. Where does buildinfo.Debian come from, and does it really
Kirk> belong?
The debian/rules file is responsible for creating it.
Kirk> OK, I assume that build (or dpkg-buildpackage or debstd or
Kirk> whatever) makes it, but I can't find this file mentioned in any
Kirk> of the documentation. If it is something that we are encouraged
Kirk> to include in the .deb, then why isn't it mentioned in the
Kirk> Policy or Packaging manual?
Cause it is not standard. I think some helper package or the
other decided to create this.
Kirk> It lists the version of packages containing various development
Kirk> tools. But for my packages makeinfo is an important tool, and
Kirk> tetex-bin is not listed in buildinfo.Debian. Should I do
Kirk> something to include it?
Buildinfo is just a help for diagnostic puposes. I don't think
it has changed drastically in years, knowing the version on
some users machine is unlikely to be of use.
Kirk> 2. Do I need to do something special because I use makeinfo to
Kirk> build the packages?
I don't, genrally. When we have source dependencies, this may
be more of an issue.
Kirk> makeinfo is from tetex-bin which is a "Standard" package. Might
Kirk> it not be considered a standard development tool, and do I need
Kirk> to document its use somewhere?
Not until we get source dependencies.
Kirk> 3. Why doesn't debstd gzip README.debian?
Kirk> Well, why doesn't debstd gzip README.debian? It does gzip the
Kirk> documentation mentioned on the "debstd" line of the debian/rules
Kirk> file.
I do not have debmake on my machine, so I do not know.
Kirk> 4. Should I edit the README to remove build information?
Kirk> Section 5.3 "Additional documentation" of the policy manual
Kirk> says:
Kirk> It is often a good idea to put text information files (READMEs,
Kirk> changelogs, and so forth) that come with the source package in
Kirk> /usr/doc/package in the binary package. However, you don't need
Kirk> to install the instructions for building and installing the
Kirk> package, of course!
Kirk> If the source package includes a README which contains some
Kirk> useful information, but which mostly talks about the build
Kirk> process, should I include it in its entirety, or may I edit out
Kirk> the build instructions?
Probably.
Kirk> 6. Why does `dpkg -I *.deb' say "new debian package"?
As opposed to truly ancient debian package format ;-)
Kirk> 7. Why do I get *_i386.changes when Architecture = all?
Ignore this, dpkg has more serious bugs than just this one.
Kirk> 8. Why is build complaining about "no utmp entry available"?
Ignore this, dpkg has more serious bugs than just this one.
manoj
--
Trust no future howe'er pleasant! Let the dead past bury its dead!
Act--act in the living present! Heart within and God o'erhead! --
Longfellow
Manoj Srivastava <srivasta@acm.org> <http://www.datasync.com/%7Esrivasta/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
Reply to: