Re: Feaping Creature-ism in core Debian Packages
Dale Scheetz wrote:
> Look Joey, you have taken my comments much to personally.
No I haven't. As I said, I don't _care_ if you use debhelper or not, or if
anyone does. I welcomed constructuve comments like yours _two_years_ago_,
and they made the initial design of debhelper much better. And I did ignore
some of them, hoping perhaps something would one day come along that was
better than debhelper and managed to address them. But I'm not hearing a
single thing from you regarding helper tools that I didn't hear two years
ago. Perhaps my memory is just too good for random topics discussed on
mailing lists, but repeating a topic like that bores me.
> 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.
In one paragraph, you accuse me of being too "relaxed". In the next, too
"rigid, inflexible". Please make up your mind. You're the one who's coming
off as rigid to me, if you think we should restrict ourselves to a single
language for everything, or a single method for building packages.
The best thingh about the debian package build system is the tremendous
amount of flexability it gives you to build your package however you want.
Debmake, debhelper, yada, and the countless different handrolled rules files
are just a natural outgrowth of that flexability.
Returning to the real issue, I would love to see us implement source
dependancies (the policy proposal has been accepted), stick them in all the
packages, and use that data to do a thorough analysis of just how nasty the
chains of build-time dependancies really are, and also find places where
it's impossible to port something cleanly because of source dependancy
loops. Then would be the time to discuss taking action.
--
see shy jo
Reply to: