Re: Ignoramus' Guide to Deb-Make
Christian Leutloff wrote:
> Will Lowe <harpo@udel.edu> writes:
>
> > I'd like to stick to something like the form I've got going on the site,
> > but if those interested in helping can come to another consensus, I'm
> > certainly willing to change. I just think a lot of new developers (myself
> > included) get mired down in trying to get it right, and I'm trying to
> > help.
>
> The IMHO most important thing is to have as less as possible rules for
> the new maintainer to think off, i.e. the aspect of compressing/naming
> changelogs: the only thing a maintainer has to do is to identify the
> upstream changelog and provide this information to
> dh_installchangelogs. The rest like compressing, the right naming
> belongs to this script and not to the new maintainer.
>
> This way it's pretty easy for each maintainer to follow the policy
> without knowing to much about it. And if policy changes, these changes
> are reflected in the helper scripts and voila all new packages are
> following the new policy.
Here, I strongly disagree. 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.
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.
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.
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.
[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.
[2] When I say "debmake and debhelper", I only mean only those parts of it
which are called in the rules file. I do like tools such as dch, deblint, debc,
deb-make and others.
--
Proudly running Debian Linux! Linux vs. Windows is a no-Win situation....
Igor Grobman igor@debian.org igor@digicron.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: