On Wed, 2007-12-26 at 10:11 +0100, liran tal wrote: > 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, The NM Guide has to start somewhere and it starts with a compiled package (Architecture: any) because that is probably the most common starter package. 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 package. 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. > * Wrong 'Architecture:' in debian/control > > If I look at > http://www.debian.org/doc/maint-guide/ch-dreq.en.html#s-control > The example on line 9 shows exactly that: 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. > I'm not sure what you mean but I have attempted to "fix" the > description > You could be more clear on what is a correct spacing/indentation and > punctuation/layout? lintian -i is fairly clear, as is simply comparing with existing packages. > I've removed the Homepage from the description and added it as a > line of it's own sorrounded by < > as seen elsewhere. That support has changed recently and the guide is yet to be updated. 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. > * 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? The NM guide does cover ITP bugs. File an ITP. An RFS is not the same as an ITP. > 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. > 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 No, you were guided to not change the .orig.tar.gz but create a .diff.gz instead, consisting of the contents of the debian/ directory. It is these files that determine what ends up inside the .deb - principally debian/rules. 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/. > I create because that is the upstream package and it should contain no > source files. Don't change the upstream package without very good reason - whatever 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. > * Out-of-date Standards-Version in debian/control > > What should it be set to? You are fully capable of finding that out for yourself. You need to be 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 all. > * 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. Debconf isn't easy for new starters - hence it may be best to forget 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. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
signature.asc
Description: This is a digitally signed message part