Re: Feaping Creature-ism in core Debian Packages
On Tue, 31 Aug 1999, Joey Hess wrote:
> 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.
Sorry you're bored. I still say that you are taking this personally, and I
say that because you still insist that the thrust of my arguments pertain
to the use of debmake. It isn't. While debmake is one of the items that I
have listed and discussed, as relates to creeping featurism, it isn't the
only one. The fact that you return to this (and perl) as the "subjects" of
my rant means you haven't heard what I have been trying to say.
>
> > 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
Because your position is confusing to me. Some points seem to rigid while
other points contradict that rigidity...
> 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.
>
That isn't what I think. I _do_ think that we need to look more closely at
the way we "plan" enhancements to the packaging system, so that we make
sure we don't paint ourselves into a corner.
I do happen to agree with Ian's early insistance that the package manager
not deal with anything more than pre and post install/remove scripts.
There are good reasons for keeping the tools simple during installation. I
happen to believe that there are good reasons for keeping the tools simple
for construction as well. Complex chains of dependencies create the
potential for unresolvable interdependencies making forward motion
impossible.
> 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.
>
And while you and others are closely focused on the process of building a
package, you are creating a situation where the distribution can evolve
into a tangled mess of interconnected relationships. By focusing on the
individual packages and ignoring the integration issues the distribution
as a whole suffers.
> 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.
I am disapointed that everyone wants to see this problem as being solved
by the magic of source dependencies.
The reason dependencies work so well for Debian is that the package
management system can authenticate the shared library dependencies without
the maintainer needing to be aware of them. Additional dependencies are
added by the maintainer as they become apparent, but the shared library
dependencies follow automaticly, guaranteeing that the needed libraries
will be in place for proper execution of the binary.
Just how do you expect source dependencies to be determined in any
"automatic" fashion, as they are in binary packages? For the most part,
these dependencies are going to be discovered by experimental methods,
such as the ones I have been employing on the Ultra, and added to the
source depends list by hand. In order to make "source depends" work well,
it seems to me that we need to understand the dependencies of the
important source packages well enough to plan a functional strategy for
implimenting source dependencies.
My questions/complaints about debhelper, debstd, yada, etc... stemmed from
the obvious potential for circular dependencies in source that could make
correct construction of packages difficult, if not impossible.
I'm just asking for better planning rather than the asyncronous
implimentation of arbitrary ideas by individual maintainers. My suggestion
that these helper packages not make the target package dependent upon
themselves is only one way to approach the problem. We could also
institute policy that would raise the priority level of a set of these
tools to important, making sure that they will always be available when
building packages.
While I admit that some of my tone comes from the frustration of trying to
build a connected set of packages, only to find that at every step you
need one more little bit of package management fluff from yet another
package before you can build the next package on your list. We simply need
a better implimentation plan than our current one, or we are going to find
ourselves painted into that proverbial corner.
Luck,
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: