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