On Wed, 2007-12-26 at 10:11 +0100, liran tal wrote:The NM Guide has to start somewhere and it starts with a compiled
> I am doing everything in my power to get this package built right.
> There is an enormous amount of pages about building debian packages
> and none of them is consistent about how to build such package.
> Unfortunately the New Maintainer's Guide is hardly friendly,
package (Architecture: any) because that is probably the most common
Just an idea. Forget daloradious for now. Find a small compiled
(non-native) package that you already use. Get the Debian source using
'apt-get source' and rebuild it without changes. Copy the .orig.tar.gz
to a new directory and unpack it. Now debianise that source following
the guide and build a test package. Compare the *contents* of your
package against the real debian package using debdiff. Compare the
*.diff.gz* (the differences from upstream from the debian/ directory)
using interdiff -z. It doesn't matter if the files in debian/ are
different, concentrate on getting the same results as the existing
I'm not going to spell it out for you, you should be able to find those
tools, install the package(s) that provides them and read the manpages
to learn how to use them. Packaging for Debian is all about using
existing examples and guides on your own initiative.
Because the example is a compiled package, yours is not. The guide
cannot take you through *your* package - it has to assume that you know
enough about your own package to discriminate between the example and
your own package.
lintian -i is fairly clear, as is simply comparing with existing
> I'm not sure what you mean but I have attempted to "fix" the
> You could be more clear on what is a correct spacing/indentation and
That support has changed recently and the guide is yet to be updated.
> I've removed the Homepage from the description and added it as a
> line of it's own sorrounded by < > as seen elsewhere.
The current practice is to put a Homepage: field in the source section
of debian/control without < > around the url. Things are always changing
within Debian - you need to ensure you keep up to date. The various
guides are not always up to the minute but you should be.
The NM guide does cover ITP bugs. File an ITP. An RFS is not the same as
> * Missing ITP number from debian/changelog
> Do you mean stating in the changelog that it closes some bug
> or rfs? Where is the ITP number coming from?
> In addition:
> * The package simply does not work - no files are installed.
> That's exactly what I stated in my last email which no one replied.No, you were guided to not change the .orig.tar.gz but create a .diff.gz
> You have guided me to have an .orig.tar.gz tarball which is exactly
> my original package and NOT to put any of these files in the package
instead, consisting of the contents of the debian/ directory. It is
these files that determine what ends up inside the .deb - principally
Your package should not be native so you need a 0.1.2-1 type version
string. You need to pass the upstream .tar.gz to dh-make so that
a .orig.tar.gz can be made. Building the package will then create
a .diff.gz consisting of the changes you made in debian/.
Don't change the upstream package without very good reason - whatever
> I create because that is the upstream package and it should contain no
> source files.
you download from the upstream site should be preserved as .orig.tar.gz
and in most cases that is fine. Whatever upstream package, whatever it
contains, you generally leave it alone. When the package is built, the
changes needed to make a Debian package are what generate the .diff.gz.
You are fully capable of finding that out for yourself. You need to be
> * Out-of-date Standards-Version in debian/control
> What should it be set to?
able to use the resources available. If you cannot find out information
like that from the web pages generated for every package in Debian, you
might need to reassess whether you want to be packaging for Debian at
Debconf isn't easy for new starters - hence it may be best to forget
> * Maintainer scripts are using `read`. You should use Debconf
> to ask users
> questions like this. It has many, many benefits over `read'.
> I will take another look at some manual for proper Debconf usage
> for the maintenance scripts.
daloradius for some time. Start with a different package that doesn't
use PHP, doesn't need debconf, doesn't have complicated maintainer
script requirements and is more like a typical, upstream, compiled
package that fits the NM guide more closely. Maintainer scripts
themselves are not something I would recommend that you worry about at
this stage. I seems to me that you haven't learnt the rest of the
packaging system yet and you need to be familiar with how other packages
work before trying to understand the complexities of maintainer scripts.