[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

Too many posts in this thread in too short a period of time had left
me dizzy.  What can I say? :-)


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: