Igor Grobman <igor@digicron.com> writes: > 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. They're only shell scripts. You can use and compile the whole package without the rules file. Only for making the package again you have to install more shell scripts. No porting is needed. Where's the problem?? > That is only one problem with those tools. Another major problem is that they > hide what they are doing. Where's the problem with that fact?? You don't see how memory is allocated to the Linux kernel, but you can make new programs ... > It is my belief that the maintainer > should know exactly what's going with his package. I don't *want* to know that! I only want a package that fits well in the Debian system with minimal extra effort. > Also, look at 100+ bugs filled against packages with copyright file > compressed. Most of those packages use debstd. BUT to fix it, you have to implement the compressed copyright file into the appropriate script and repack each package again. No need to edit each package. Pretty easy to correct each package with minimal effort. I want to get good packages with the least possible afford for the maintainer. I can drive a car with out knowing how the machine works. Why shouldn't I pack a program for Debian without knowing about the things that scripts can do for me???? Bye Christian -- Christian Leutloff, Aachen, Germany leutloff@sundancer.oche.de http://www.oche.de/~leutloff/ Debian GNU/Linux 1.3.1! Mehr unter http://www.de.debian.org/
Attachment:
pgpKr2hmut9sJ.pgp
Description: PGP signature