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

Re: Thoughts about src-dep implementation



On Thu, Oct 28, 1999 at 01:16:49PM +0200, Roman Hodek wrote:
> 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.

No, the problem is where to find the information after the source is
unpacked. And you gave the answer: In the dsc file. It should be copied to
the target directory (the parent directory of the package tree) by
dpkg-source -x just as the orig.tar.gz file is.

> If dpkg-buildpackage starts, you don't need
> to have the .dsc; you could already have deleted it.

So don delete it if you still want to check source dependencies.

> 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...

It can be copied along with the orig tar gz.

> Therefore my suggestion to store the src-dep information somewhere in
> a file in the build tree. Do you have better ideas?

I think my idea above is better, because it leaves the critical information
into the place where it belongs. Are there any disadvantages with my
suggestion?

> > 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?

For simple cases, there is no magic. But if the dependencies are complex,
for example because they nivolve virtual packages or complex version
dependencies, the correct actions to perfom are better figured out by human
with the help of apt. Duplicating all the logic in yet another tool seems to
be superflous(sp?) to me.

> > 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.)

I was just agreeing with you.

Thanks,
Marcus

-- 
"The purpose of Free Software is Free Software.
The End and the Means are the same."  -- Craig Sanders

Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de>


Reply to: