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 <[EMAIL PROTECTED]> -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
