> I would also appreciate it if someone could give my packages a quick
> look before I upload them to Incoming. I could either put them in my
> home directory on master or in an obscure corner of my web page. Were
> I to do that and then decide that I wanted to change something, would
> I have to bump up the release number, or would it be OK to keep the
> same release number since the package had not been uploaded to
> Incoming and it had been clearly marked as a not-yet-official package.
Well, it's your decision. Policy does not (and cannot) rule on this one. I
would not bump the release number unless it's something substantial that
changed.
>
>
> 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.
Well, this automation is something some of us don't like. I prefer to do
everything by hand(i.e. don't use debstd or any other debian-specific tools in
the debian/rules), although when I was getting started, I used debstd too.
dh_helper package is becoming more and more popular it seems. I am still a
little wary of the idea, but at least it hides a lot less from you ;).
>
>
> 1. Where does buildinfo.Debian come from, and does it really belong?
>
> 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?
>
> 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?
buildinfo.debian is generated by debstd. You are right, it's neither required
nor discouraged by policy, but AFAIK only debstd generates it. I think it
might be useful, so i wouldn't go to the trouble of deleting it from the
package.
>
>
> 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?
No, we don't have Source-depends: right now, so you don't have to document the
use of makeinfo anywhere (you can list it in the buildinfo.debian of course).
>
>
> 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 only gzips documentation that's bigger than some set size. It is in
compliance with the policy too.
>
> 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?
>
I would include it as is. Editing it would be messing with upstream work which
is discouraged by debian.
>
> 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?
if you mean debian/tmp/DEBIAN/control, then they shouldn't be there.
>
>
> 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.
"New debian package" means it's the "new source format" package, and not what
you thought :).
>
>
> 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.)
No, this is right. I am not sure of the reasoning behind this, but this is
how dpkg always spits it out.
>
>
> 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?
No, this is a known harmless bug which is apparently fixed in the alpha
dpkg version Klee released a while ago.
--
Proudly running Debian Linux! Linux vs. Windows is a no-Win situation....
Igor Grobman [EMAIL PROTECTED] [EMAIL PROTECTED]
