Re: Feaping Creature-ism in core Debian Packages
On Thu, 2 Sep 1999, Joey Hess wrote:
> Dale Scheetz wrote:
> > 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's debhelper. Say anything you like about debmake, I doubt I'll disagree.
There are just so many to choose from ;-)
Of course I _meant_ debhelper, even if my fingers didn't...
> > 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.
> As you may have noticed, I went on to say:
> > > 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.
> Automated dependancies work for <5 minutes of furious grepping of the
> available file, (and yes gratuitius use of perl) ensue> roughly 70% of all
> dependancies. The other 30% of all dependancies are non-library dependancies
> which cannot easily be automatically detected.
> > 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?
> Any source package that generates binaries that link with libraries, will
> source-dpend on those libraries, and on the associated -dev packages. This
> is a simple rule of thumb (I'm sure it fails occasionally) that could be
> automated. That catches just as many source dependancies as the automatic
> binary dependancy generation. If we really wanted to, more could be arrived
> at by various hueristics, like grepping perl programs for "use <library>"
> IIRC, part of the source dependancy spec we have now agreed on on
> debian-policy includes a list of packages that are analagous to Essential
> packages, and are just assumed to be installed on any system you build a
> package on. That removes a large number of source dependancies.
Care must be taken that these Essential packages can be built using only
Essential packages, or does this not seem necessary from your POV?
> As for the remainder, Debian is full of people that know their packages, and
> can come up with source dependancies with relative ease. Some
> experimentation will have to be done. It won't happen overnight. But why do
> you think it won't eventually lead to a complete set of source dependancies?
There just seem to be too many cracks to slip through. However, the strace
idea provides a reasonably foolproof way to check out the complete build,
so I probably don't feel as strongly about this as a problem as I did
> Going a step further, it has been proposed in the past that the build
> process of packages be straced, which lets you see every file the build
> process tries to use or exec. Then you can generate source dependancies from
> that, that cover every single dependancy. I think this idea is still blue-sky.
Yep, I like this one ;-)
> > 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.
> I don't get it. Source dependancies source-depend on source depenandices?
What I was trying to say was: We should not plan out our source-dependency
strategy in a vaccuum, but should try to look at just how tangled the
situation is currently, and design a source dependency strategy that meets
the requirements of the circumstances.
> I think we understand how packages build well enough to be able to specify a
> format to use for listing source dependancies. And that's what we've done so
> far. If we really managed to goof that up, we can always fix it.
I'm sorry, I guess I'm just too paranoid, but I can see possibilities that
may not have simple fixes.
Our current situation is that we don't have the protection of source
dependencies. As you have pointed out, each developer knows his own
packages well enought to know what is needed to build it. You have also
pointed out that most of us developers have at the very least a "standard"
system, and most of us have much more that that installed from the devel
section. This creates situations where it isn't just obvious, even to the
maintainer, just which packages are being used to build the package.
You, and others, have suggested an strace like build process that would
identify every call made. I think this is an excellent idea and we should
all spend some time taking a look at our packages to get clear ideas of
what these dependencies are.
You have also suggested that I am only concerned with bootstrapping. This
is not the case. While I have discovered many of the issues I have been
speaking to by this minimal build process, my major concern is that we are
slowly drifting into a situation (without having source depends to protect
us) where it may not be possible to build a given package because of
dependencies that can not be met starting with a current system, making
the build of a new system impossible. Yes, I noticed these effects while
doing a bootstrapping opperation on the Ultra, but I don't think that
bootstrapping is the only place that such problems will appear.
I don't suggest that we are yet in the catch-22 situation I fear. I mearly
suggest that we should look closely at the situation and do our best to
prevent the deadlock situation from occurring. For the most part, all I
have heard is defensive posturing about the particular packages I
interacted with during my discovery process. While this is understandable,
it isn't very productive.
On the other hand, I think that several good ideas have come out of this
discssion, so I want to take this opportunity to thank you for
participating, rather than "going away mad".
_-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_-
aka Dale Scheetz Phone: 1 (850) 656-9769
Flexible Software 11000 McCrackin Road
e-mail: firstname.lastname@example.org Tallahassee, FL 32308
_-_-_-_-_-_- See www.linuxpress.com for more details _-_-_-_-_-_-_-