Re: Feaping Creature-ism in core Debian Packages
On Tue, 31 Aug 1999, Joey Hess wrote:
> Dale Scheetz wrote:
> > Well, I _do_ have perl installed, and here is the build.log from my
> > attempt:
>
> Ok, it needs perl-5.005 for it's regression test.
So, before I can build the helper tool I must be able to build perl-5.005.
This is exactly the creaping featurism I'm trying to address here, and it
has nothing to do with bashing perl. Perl is no better and no worse than
the other options (like python) that have been suggested by some as
"better" tools. My point is that we have dropped restrictions on install
scripts to the point that anything is likely to appear as an obstruction
to the build process. Perl is only one example.
>
> I'm not going to respond to the rest, because I have long ago anwsered every
> complaint you have. Some by ignoring them, and some by adding things like
> --verbose to debhelper. It was all discussed two years ago, and I don't see
> any need to discuss it again.
Yes, you _have_ continued to ignore my complaints and made orthogonal
corrections identifying them as "solutions" to my complaints.
This is not a complaint about your programming skills. The package you
have built is pretty tight and built to your specifications. My objections
have been to your design spec, and the impositions it places on
integration of the distribution. I'm sorry that you are unwilling to
discuss these particular issues, as a helper tool _is_ a good idea.
>
> You're welcome to write a tool you like better. I don't think you have much
> business trying to tell other what tool to use though.
I have all the tools I need to build packages. If I follow the processes
outlined in the programmers manual (without recourse to any helpers) dpkg
and dpkg-devel are the only packages I need (aside from the other standard
tools like make etc...). My personal preferences don't really enter into
this discussion. My position is that adding more helper tools only makes
the problem worse, not better.
If I have no business dicussing the usefulness of various tools produced
by Debian, then what the F**K must I do to gain that right?! I certainly
_do_ have the right to make suggestions to this group. If you don't like
my suggestions, then make some of your own, but don't tell me I can't say
the things I have said because of some nebulous lack of qualifications.
Look Joey, you have taken my comments much to personally. While I admit to
using your tool as an example, I was talking about the general problem of
a plethora of helper tools that work like debhelper. Each time someone
uses Yet Another Helper Tool on their package, that tool automatically
becomes required for building that package, when the tool inserts parts of
itself as calls in the rules file. Such a process, devoid of design review
and oversite control, run by whatever developer wants to tackle the
"problem", can only tangle up the integration process that we are all
about. To take the pressure off of you, bison depends upone debstd, which
also insists on sticking calls to itself in the rules file. In looking at
the binary-all directory where debhelper is kept, I find about five or six
other packages that suggest themselves as helper tools. Growing more tools
only increases the complexity of the integration process.
I have been with this project for a "looong" time, and have seen it grow
from under a hundred developers and an equal number of packages to the
monster that it has become today. During that time, package development
has gone from being controled and limited to only shell scripts of the pre
and post install/remove variety, into the more relaxed state we find
today. With the large number of packages and all the chances for disaster
that this creates, I don't think I'm being unreasonable in asking that we
revisit this issue yet again.
The fact that you don't agree worries me, as it indicates a rigid,
inflexible, position with respect to such important tools. Such a position
makes it difficult to even start such a design process, so please
reconsider.
>
> > My point about perl is that when you integrate more dependencies into the
> > installation process you automatically create more points of failure.
> > Allowing the infiltration of perl into installation proceedures
> > unnecessarily complexifies the process with very little gain, outside
> > allowing perl programmers to ply their trade. The fact that the upstream
> > maintainers of perl have shown historic willingness to break interfaces in
> > order to "improve" perl, suggests that such occurances will happen in the
> > future, with unknown ramifications.
>
> So have the upstream maintainers of the linux kernel. I don't see anything
> here but a bunch of anti-perl sentiment.
>
Then you aren't hearing what I am trying to say. Try letting your hackles
settle a bit and try to see what it is I'm suggesting. Your current
defensive posture is unnecessary and unproductive.
Please take my comments in the spirit in which they were offered. I'm not
out here shooting at any moving target that I see. I _am_ trying to
present some insight into complex global issues that don't reside on one
package or another's faults, but that do occur from the drift of many
packages away from the original intentions of the package system.
Joey, I consider you a smart guy (that's a compliment, not a jibe), and
I'm thus troubled when you fail to see the issue I'm trying to address.
Please give me a hand with this instead of simply throwing dirt in my
face. The project will benefit more from our cooperation than from
whatever it is we have done so far...
Waiting is,
Dwarf
--
_-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_-
aka Dale Scheetz Phone: 1 (850) 656-9769
Flexible Software 11000 McCrackin Road
e-mail: dwarf@polaris.net Tallahassee, FL 32308
_-_-_-_-_-_- See www.linuxpress.com for more details _-_-_-_-_-_-_-
Reply to: