On Wed, Nov 03, 2004 at 04:06:01PM -0600, Zach Garner wrote: > On Wed, 2004-11-03 at 21:26 +0100, Bartosz Fenski aka fEnIo wrote: > > On Wed, Nov 03, 2004 at 10:47:45AM -0600, Zach Garner wrote: > > > I'd agree it's pretty confusing, but only first time. > > It's quite easy to understand it. > I'm hoping so, that's why I'm trying not to give up too easily. > > > > Most of the apps are using `./configure && make && make install` so dh_make > > tries to use that way. > > In fact the only file you need is debian/rules. > > It should be Makefile which create your package. > > What bugs me is that as far as I can tell from the documentation, > dh_make is the recommended proper way of doing things. Also, as far as I The documentation you're reading has a target audience of people who want to create packages for Debian. The dh_make cruft is needed for lots of little things we need to make Debian as good as it is. dh_make is also initially targetted, as you've noticed, at building packages which use the old standby of ./configure; make; make install. That isn't quite the universal constant it once was, by virtue of the rise of scripting languages and Java, the former of which doesn't need building, and the latter which decided that it can't be any good because someone else is doing it that way. > can tell I need the following: > README.Debian compat copyright rules control dirs > > I understand your point though, the 'rules' file is the only one that > really matters. "A build script" is, technically, the only thing you need -- just as you would need for a tarball. However, if you want to use the helpers like debhelper, you'll need debian/rules, changelog, and control. The first is the build script, changelog is needed to get versioning information, and control is used by most scripts to get all sorts of interesting information (like what the source package is called, what the binary packages are called, and so on). > I have some makefiles that work ok, by modifying what I got from dh_make > (this is probably a bad idea, but I don't have documentation on how to > hand write one without using debhelper scripts...). Butcher those dh_make-produced systems. That's why they're "templates". > It generally works, > but there is a lot of magic that happens in the dh_ scripts. Read the manpages, both for debhelper itself, and for the individual dh_ scripts. They're pretty well documented, and each one is small enough to be (IMO) understood well. > For instance, I don't know how it knows that debian/<packagename> is where > my application data is supposed to be. Is this hardcoded in dpkg-deb? Is > somehow expressed in one of the dh_ scripts that is listed in my "binary:" > target. All I really know is that if I put my files there, it puts them in > the package. I probably need to read the man pages more than I have... That's debhelper compat magic. Back in the olden days, debhelper was more-or-less designed for single binary package work, and so it dumped it all into a directory called 'tmp' in the debian/ directory. That didn't work, so later major versions of Debhelper changed it all around. Read up on "compatibility levels" in debhelper(7). > > > Why can't debian package building be as simple as 'dpkg-create > > > foo.spec'? > > > > > > Second, why can't I create packages with standard unix commands? Why > > > can't I say something like: > > > $ tar cvzf data.tgz myapplication/* > > > $ tar czvf control.tgz control > > > $ tar czvf mypackage-0.1.deb data.tgz control.tgz > > > > Debian uses standard unix commands. > > What I meant by standard roughly translates into available on most/all > unix or linux systems. The format of a .deb file is special as far as I > can tell. I can't create or manipulate them without using dpkg-deb or > one of the other scripts. Nope. Read deb(5) (in the dpkg-dev package). Tells you all about it, in a fair amount of detail, and it's all straight-up stock Unix tools to do it. In fact, in the past, dpkg was nothing more than a shell script. > In fact, I would be happy enough if I could (a) run dpkg-deb on our > other systems, this may be possible, though I don't expect it would too > easy and (b) use dpkg-deb to create a package by giving it the > control.tgz and data.tgz. Ideally, dpkg-deb wouldn't be required to > create the specially formatted deb file, and I could just create a tar. Running the Debian packaging tools on almost any Unix-like system shouldn't be excruciatingly difficult, but as has been said a couple of times now, you don't need any of it to make Debian packages. > > > My main complaint here, is that we really want to be able to build the > > > debian packages from any developer workstation. Since we don't impose > > > operating system requirements on developers, we can't expect debian to > > > be on all workstations. > > > > Sorry. How do you suppose to build rpm without rpm? > Oh, I didn't mean to imply RPM was better here. My other biases show > here.. I started out with Slackware, and later spent quite a while in > the OpenBSD then FreeBSD world. For all of those .tgz was the standard > format. We've got ar archives instead. One problem I found with tgz blobs for slackware was it was often hard to find a package as opposed to a random tarball. Not a major problem on your install media, but a bit trickier on the Internet. > I can get over part of my complaints. I can deal with the multiple files > in the debian directory, and may come to love it. The layers of scripts, Multiple files is just like multiple sections in a .spec file. Ours are just easier to work with. <grin> > and the resulting confusing, conflicting documentation is still a > problem. But I expect I can eventually come to an understanding of it > all. You're mostly getting confused because you have wildly different requirements to most people who read the documentation. Consider: * You are building custom packages for your own (company's) use. Most newbies are looking to create (more-or-less) regular packages for Debian (or surrounds). * You have a desire (if not a requirement) to be able to build your packages on any Unix-like system. Most newbies are coming at this from their bog-stock Debian box, and may not even know there are other Unices out there. * You want to understand what's going on. Most newbies are content to chant the magic words and watch the pretty lights. <grin> That last one might be slight hyperbole. But you get the idea. > What's still the big problem for us is the need to be on a debian system > to create the packages. From what I can tell, we would likely need a few > packages from debian-unstable on that system as well. Why? Stable might be old, but you can still build packages on it. Of course, if you're targetting Unstable, then yes, having matching versions in your build environment would be of use. On that subject, your other Unix-like lovers could have Debian chroots on their systems, and use those as their build environments. A common problem in software QA is of having diverse build environments -- you want a known good basis for your debugging efforts (as much as running in differing environments exposes bugs in your code, it's still a PITA to work out whether the bug's in your code or the environment if you don't strictly have to). - Matt
Attachment:
signature.asc
Description: Digital signature