Re: Ignoramus' Guide to Deb-Make
> Igor Grobman <igor@digicron.com> writes:
>
> > Christian Leutloff wrote:
> > >
> > > Igor Grobman <igor@digicron.com> writes:
> > >
> > > > Christian Leutloff wrote:
> > > > > Will Lowe <harpo@udel.edu> writes:
> >
> > > > 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??
> > >
> >
> > The problem is that by design, the rules was supposed to be a simple makefile
> > where you could easily see what's being done. The scripts hide that. Don't
> > forget that we are talking about commands like cp, mv, install and gzip, not
> > some obscure commands noone knows about.
>
> oh, come on. Look at the names of the following shell scripts:
>
> dh_builddeb dh_installchangelogs dh_installmanpages dh_suidregister
> dh_clean dh_installcron dh_installmenu dh_testdir
> dh_compress dh_installdebfiles dh_makeshlibs dh_testroot
> dh_du dh_installdocs dh_md5sums dh_undocumented
> dh_fixperms dh_installexamples dh_strip
>
> now, tell me, where you can't estimate what they are doing.
Ok, I hope this will be my lost post on the subject. Fist, let me summarize
my thoughts on debstd which I've been criticizing for the most part in this
thread. It is designed to be a black box. By looking at debstd call in debian/
rules, I don't know exactly what it does. I have to know exactly how it
works, and I also need to look at what files exist in debian/, since debstd
automatically installs/modifies some of them. I say this makes it extremely
hard to debug packaging bugs in bigger packages.
Now, debhelper is much better in that each script has its purpose and should
do exactly what its name suggests, and I certainly hope that's the case :-).
My problem with debhelper is that each dh command can be replaced by a line
(or 2 at most) in the rules file using standard *nix commands. Why do we have
to invent our own?
> > > I don't *want* to know that! I only want a package that fits well in the
> > > Debian system with minimal extra effort.
>
> > *sigh*. You will want to know that when you get bugs against your package.
> > IMO, debugging is much easier without debstd. While we are on the topic of
> > debugging... These tools change often, so building the same package with
> > different versions of the tool can produce completely different packages. If
> > someone ever files a bug against your source package, and it's related to the
> > fact that different debstd versions were used, how long is it going to take
> > you to find that out?
>
> If've never seen a bug against a source-package. This can only be
> solved with source-depends. What I've the bug is reported with a wrong
> compiler.
>
ok, you did nulify my argument by saying that you still need the latest
dpkg-dev usually, and yes, source-depends would solve the prob.
I've seen plenty of bugs against source packages.
>
>
> We both show that there are different preffered ways of doing
> things. We should left the decision to the each maintainer and tell
> him the principel difference between the two approaches. What he
> agains and what he has to pay for it. We're developing free software
> and so we should provide each maintainer with the freedom to choose
> his tools.
That's all I've been trying to say :-).
--
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: