Re: Ignoramus' Guide to Deb-Make
On Sat, 8 Nov 1997, Igor Grobman wrote:
> Here, I strongly disagree.
And I strongly agree. :-)
> First, let me say that I was debmake fan in my
> time :-). I, too, couldn't see what people could possibly have against it.
> It makes things so much easier! That it does, but it hides what it is that
> it is doing. We pride ourselves on the fact that debian packages can be
> handled using standard *nix tools. Well, with the introduction of debstd and
> debhelper[1], we have made our packages depend on our own special tools.
>
Our packages depend on dpkg and dselect anyway. Aren't these our own
tools? It should be taken for granted that debian packages depend on
the debian platform.
>
> That is only one problem with those tools. Another major problem is that they
> hide what they are doing. looking at debstd call in a rules file, I don't
> know that it copies copyright, changelog, and README.debian files to the
> debian/tmp/usr/doc/package automatically. I don't know that it copies all
> maintainer scripts to debian/tmp/DEBIAN. I don't know a lot of other things,
> and debstd only tells you only some of what it's doing on invocation.
> Debhelper[1] is a little better in this regard. At least, you know what the
> particular script is doing. Still, I don't know exactly what it does, and
> with what permissions it installs everything, etc. This promotes maintainer's
> ignorance about the package system. It is my belief that the maintainer
> should know exactly what's going with his package.
>
First of all debstd is a script so you can just read the source if you
want to know what it's doing. Secondly, it is by design supposed to be a
black box and this IMO is a good thing. This way changes can be made to
policy in the most transparent way possible. I am myself curious about
what things do and how they work but I don't think a person should _have_
to know these things. To make a Windows analogy you can program at the
API level in C++ and have full control though your programs will take much
longer to write or you can use Visual Basic to knit together a program
quickly at the cost of some power. When I do Windows programming, having
that choice of style gives me flexibility in how I approach projects.
Debian programmers should have that choice too.
> Another disadvantage is that the functionality of the tool changes with time.
> A debstd or dh_manpages call in the rules file can do one thing in this
> release of the package, and something completely different the next. I don't
> see how this automatic compliance with latest policy that you, Christian, are
> advocating is any good. The _maintainer_ should know the policy, not the tool.
> Look at the discussion of bug#14623 where Christoph is disputing the current
> _policy_ and is refusing to put the requested functionality in debstd. The
> issue being discussed is not a fundamental one, and I am sure Christoph will
> eventually fix it once he is convinced. However, the precedent is there.
> Also, look at 100+ bugs filled against packages with copyright file
> compressed. Most of those packages use debstd. It's just one example where a
> huge number of packages is broken, because they used a broken tool.
>
But by the same token those 100 bugs could be fixed trivially just by
upgrading the tool.
> I believe debmake and debhelper[2] are broken in their design and shouldn't be
> used, except for small packages which are indeed easier to package with those
> tools. I found that fixing packaging bugs is much easier when I got rid of
> debstd call in most of my packages.
>
I have yet to take on any really complex packages so I can't speak from
experience but many packages are created with debmake now. Can we really
say they are on average more buggy than non-debmake packages?
And even if the particular implementation (debmake) is broken, I still
don't think that says anything about the basic soundness of the black box
approach.
> [1] I haven't found time to try debhelper yet, but based on what I read, it is
> debstd broken into smaller scripts which each do a specific task. This is
> indeed better than debstd, but still suffers from most problems described
> above.
>
My next project is going to be to learn about using debhelper. Who knows
I may soon be agreeing with you. :-)
--
Jaldhar H. Vyas <jaldhar@braincells.com>
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-doc-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: