Re: Thoughts about src-dep implementation
Roman Hodek <Roman.Hodek@informatik.uni-erlangen.de> writes:
> Because auto-generating parts of src-deps saves a lot of work and
> errors for the maintainers, just like auto-generating parts of binary
> deps does...
*Parts*, fine, I have no problem with parts. I was just a little
croggled by the example of trying to autogenerate *all* source
dependencies for the debian-policy package.
I think it may turn out to be more hairy than we think. For example,
many packages will require awk to build. Ok, but we have several awk
packages -- which one will the source-depends use? Awk is a virtual
package -- is this source-dependency-building tool going to figure
that out? That would require some moderately sophisticated AI, I
suspect. What about code that requires a java or IDL compiler, but
doesn't care which one? Too much room for confusion and chaos.
I'd rather have a limited and controlled tool that doesn't go
overboard. It may not be *as* useful, but it's also less likely to
fail catastrophically.
> > Here's something no one has mentioned: why not extend the shlibs
> > format to include the necessary -dev package?
> That's more or less what I suggested...
Ah, ok, well that part I approve of. I'm sorry if I picked on your
post -- I was really trying to comment on the whole thread. It was
really the whole idea of a process monitor which tries to infer *all*
source dependencies that I object to. There is too much scope for
something to go wrong with a tool like that. For some reason, I
thought that was what you were advocating, and I apologize for the
misinterpretation.
Too many posts in this thread in too short a period of time had left
me dizzy. What can I say? :-)
cheers
--
Chris Waters xtifr@dsp.net | I have a truly elegant proof of the
or xtifr@debian.org | above, but it is too long to fit into
http://www.dsp.net/xtifr | this .signature file.
Reply to: