Re: Feaping Creature-ism in core Debian Packages
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.
:-P
> 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.
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?
<aside>
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.
</aside>
> 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?
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.
--
see shy jo
Reply to: