Re: Thoughts about src-dep implementation
> > - dpkg-source extracts the Build-* fields from the .dsc and writes
> > them to debian/build-depends.
>
> Sounds a bit too much like magic for me. It should not be necessary to make
> such wiggles to build a package succesfully. By all means make this
> optional. Working from the dsc is fine for me, for example.
>
> Your argumentation shows probably that there is a flaw in how the dsc
> file is handled. Instead hacking around symptoms, we should reconsider the
> whole setup and seek for a clean solution (with clean I mean something that
> not only works, but has some aesthetic and conceptual merit :)
I don't think it's magic... The problem I try to solve is the
following: dpkg-buildpackage works on an unpacked source tree. But
src-deps are stored in the .dsc (they really belong there, and this
also allows src-dep checking before unpacking or even fetching source
files.) So, the problem is to pass the src-dep information from the
.dsc into the build tree. If dpkg-buildpackage starts, you don't need
to have the .dsc; you could already have deleted it. Also, if it's
still around, dpkg-buildpackage can't know where it is... Source could
have been extracted with:
dpkg-source -x foo_1.0-1.dsc
or
dpkg-source -sn -x /some/strange/path/foo_1.0-1.dsc
And dpkg-buildpackage later cannot know where the .dsc was...
Therefore my suggestion to store the src-dep information somewhere in
a file in the build tree. Do you have better ideas?
> I would prefer to leave all magic to apt. The only job dpkg-buildpackage
> should optionally do is verification, which is a yes/no decision mostly.
> Returning a status like U/I/R, is not something I would like to se at this
> place.
Again, where's the magic? dpkg-check-srcdeps just compares the
status und versions of installed packages with what is required. The
info if it's a new install (I), an upgrade (U) or downgrade (D) is
then available anyway (it's just comparing version numbers). Of course
we could merge the answers IUD into one (e.g. I), but this throws away
some information that is at hand anyway. (sbuild doesn't distinguish
between I and U, but D currently is impossible, so it needs to know.)
> All of this does not belong in the standard setup, IMHO.
...what I also expressed explicitly. (I said, this should be enabled
by a special option.)
> This can be an entirely independent project, too.
Yes, and I said that (I hope it was clear). I just wanted to make
aware of possible solutions and problems.
> All my object files with debugging symbols would be lost !!! This is
> not a good idea. To me it shows that trying to be overly clever with
> automagically depends generation backfires too easily.
The source-after-build idea has died anyway, see previous posts.
Roman
Reply to: