Re: Thoughts about src-dep implementation
Roman Hodek <Roman.Hodek@informatik.uni-erlangen.de> writes:
> The problem with this: Currently the .dsc is built before
> compiling, and thus the Build-* fields have to be known before
> dpkg-shlibdeps is run. But there's an easy solution (IMHO): Why
> don't we build the source package after the binaries?
Actually, I normally don't build the source package at all until I'm
happy with the binary package.
Also, this would rely on "debian/rules clean" completely reversing the
effect of a build, and I can tell you right now, this was not true of
*any* package I have adopted, and is still not true of at least one
package I'm currently maintaining (haven't had time, plus there's one
especially tricky bit).
Up till now, if "debian/rules clean" didn't work 100%, almost nobody
would notice, which means that, mostly, it doesn't. If we suddenly
start relying on it working 100%, we'll be in big trouble! :-)
Furthermore, what *about* "dpkg-source -b"? Currently, it just runs;
it makes no assumptions about anything. Now you're saying that it has
to assume that "debian/rules binary" has been run. That's a pretty
drastic change.
> This would speed up the development cycle anyway, because as
> long as you're experimenting you currently often build the src
> package unnecessarily.
If you're concerned about speed, you shouldn't *be* building the
source package until you're ready -- I don't. (And I'm not
particularly concerned with speed.)
> Also, you automatically have cleaned source trees after
> dpkg-buildpackage, which can save some disk space if you maintain
> lots of packages :-)
Would save NO disk space for me, since I ALWAYS remove the build
directories after I finish building the package. So, it would just
result in the waste of the time required to clean up stuff that's
about to disappear anyway. :-)
So, here's what I see as the relevent points:
1) The diff *must* be generated first; either that, or we must fix
some unknown but probably very large percentage of existing
packages before we can move forward.
2) The *full* build dependencies can't really be known till you build
the package.
But I'm not entirely sure that point 2 is a major issue. Look at
binary packages: we automatically generate only the *easy*
dependencies (shared libs and the like). If a program execs some
other program, we leave it up to the package maintainer to notice and
declare the dependency. Most of our users are more concerned with
binary package dependencies -- why should we spend so much extra work
on getting the source dependencies perfect when the binary
dependencies are still so often at the mercy of the maintainer?
Here's something no one has mentioned: why not extend the shlibs
format to include the necessary -dev package? Seems to me that that
would be a lot easier and quicker and would do *most* of what we need
in most cases. And wouldn't require major (and backwards-
incompatible) changes to our whole package generation mechanism).
Remember the old adage: an adequate solution that works is better than
a perfect solution that doesn't. :-)
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: