Re: source dependencies - and recomndations
Steve Greenland wrote:
> How about not. Instead, just make the "Source-Depends:" list the tools
> needed to build the package *as it was built for Debian*.
Becuase, the package is built differently for different architectures.
In my example of xaos, which Source-Recommends: svgalib1 , it is not built
with svgalib on architectures (like m68k), that don't have svgalib.
> Otherwise
> you're expecting the developers to trace through the configure scripts
> and make files, and figure out what's essential and what just has nice
> benefits.
You're free to just use Source-Depends and leave the Source-Recommends out,
until someone files a bug asking you to change it. I don't think this
involves much extra work.
> I think the use of the word "Depends" is a little misleading --
Personally, I don't care what it's called. I think following the Depends,
Reccommends, (Suggests?) structure we already have for dpkg makes it easily
understandable by maintainers.
> surely we're not trying to enforce anything here, as we are with the
> binary Depends/Recommends/Suggests fields. We're trying to list the
> *unusual* tools that are necessary to build the package in the way
> Debian builds it, so the person doesn't have to sit and watch the
> configure or make fail six different ways before the package gets
> built. OTOH, if I download a source package, unpack it, and tell it to
> run configure/make/whatever, it damn well better do it, with complaining
> about missing "Source-Depends". (Maybe I have the tool installed in
> /usr/local...or maybe I'm just being contrary.)
The point of Source-Depends is not for the casual package compiler, it's for
autocompiling. You _need_ to know, for autocompiling, what packages can be
compiled with the tools you have available, and what tools you need to
install to compile the rest.
I don't think anyone has ever propsed that source dependancies will be
checked before you can unpack a source package, or in the debian/rules.
> I personally think the whole thing could be accomplished with a
> note in a debian/README.rebuild file, except for the convenience In
> seeing the needs listed in some convenient database. (Yeah, I know,
> auto-rebuilding. But isn't it likely that most autorebuilds will be done
> on systems that are pretty much complete, and run by people who can look
> at the log and figure out that they need to look at the README.rebuild
> file for the x, y, and z packages?)
My system was recently used for autocompiling the full distribution. It's
pretty darned complete (464 packages installed). Let's see here...
In the directory with the failed build logs in it, we have a total of 151071
lines of logfiles. Someone has to pick over those and figure out what went
wrong. AFAIK, Andreas hasn't even begun to do so, so I don't know what
percentage of these are due to unfullfilled dependancies. But it's a big
job, and having source dependancies will make it a lot easier. At least then
we'll know, if a package failed to build, it's not our fault for not having
some package installed on the build machine, so we can pass the build log
on to the maintainer and let them read it and figure out how to fix the
problem.
--
see shy jo
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: