On Wed, Nov 03, 2004 at 10:47:45AM -0600, Zach Garner wrote:
> First:
> 1. The sheer number of helper scripts, with layers and layers of
> scripts built on top of each other is really confusing.
Diversity is often seen as a virtue. That does mean that it can be hard to
separate the need from the want, but you really can ignore pretty much every
script out there if you really really want to. But take note -- it's a lot
harder to do it all by hand. Some of the people who wrote helper scripts
knew what they were doing...
> 2. The number of files that I have to create within the /debian
> directory is difficult to deal with, and having to create the /debian
> directory within my application directory and being forced to name my
> application directory according to debian rules is very irritating.
You're not forced to name your top-level directory anything, dh_make just
gets a little anxious if you don't. So don't use dh_make -- it's not a good
fit for some situations, anyway. As for the number of files, you can get
away with none if you really wanted to, but several little files is
much easier to deal with than one large one, IMO.
> 3. Most of the package creation scripts (I'm refering explicitly to
> dh_make which is supposed to be the proper way of creating a package, as
> discussed in the New Maintainer's Guide)
You're not a New Maintainer, so the New Maintainer's Guide is going to be of
limited help to you. As I mentioned in another of my missives on this
subject, you're not doing things the way the manual expects. Hence the
manual seems less helpful than it might otherwise be. Consider it an
optimisation problem -- you're not processable via the fast path. <grin>
> expect that you are building a
> traditional unix application, that's written in C, has ./configure and a
> Makefile. All we are doing in most of our packages is installing some
> files. Why can't that be simple?
Because simplicity only works when you're doing what the tool expects.
> I feel that RPM creation is better here. One command ('rpmbuild') is
> used. One file, the <package>.spec file, is needed with different
> sections for each part. I can keep my rpm packaging files any where I
> want it, and I don't have to have my application directory conform to
> any debian rules.
I'd hope that creating an RPM wouldn't require you to have your application
directory conform to any debian rules...
Let me rewrite your sentence:
"I feel than .deb creation is better here. One command
('dpkg-buildpackage') is used. One directory, debian/, is needed with
different files for each purpose. I keep my .deb packaging files in a
consistently named location, which helps others understand what I've done,
and I don't have to have my application directory conform to any RPM rules."
> Why can't debian package building be as simple as 'dpkg-create
> foo.spec'?
It's even easier than that -- you don't need to specify a .spec file.
> 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
You can. But you know that by now.
> 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.
And you're shipping the packages that these developers create on random
platforms to your customers? Eep.
> Right now, using Debian to deploy our software seems more and more
> difficult for us. I'd greatly appreciate any advice or comments. All I
> want to be able to do is create a package on any unix system that can be
> installed via apt-get, that simply installs some files, and can use the
> pre/post install/remove scripts. This seems like a simple thing to do,
> but the process seems very difficult.
It seems difficult because you're coming at this cold, without previous
packaging experience doing the more "normal" packaging first. With a bit of
experience doing regular packaging, you'd know what really is needed and not
needed, and how much dh_make can be full of crap sometimes, and this whole
process would be a whole hell of a lot easier.
But stick with it. Everything you've described thus far can be done with
.debs.
- Matt
Attachment:
signature.asc
Description: Digital signature