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.
true :-). It just occured to me that dpkg has to be used in the binary phase
anyway.
>
> >
> > 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.
This is where we disagree. A black box approach makes it harder to debug
packaging errors as I already mentioned. Let me remind you again that
commands those files perform are not something very obscure but usually comes
down to these 4: cp, mv, install, gzip
>
> > 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.
Yes, but what if someone tries to build that package using the stable version
of debstd? voila! they get the buggy package. This does not apply
specifically to this case, because the policy was not as firm when bo was
released.
>
> > 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?
I am tempted to say yes :-), but I don't know.
>
> 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. :-)
:-)
This thread is getting way offtopic. This has been argued many times already,
and we still have people on both sides of the argument :-). All that I am
trying to say is that the new maintainers should know that these tools are not
the only way. Further, in the opinion of a considerable number of maintainers,
those tools are far from the best way either.
--
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: