> Ian Jackson dijo [Thu, Oct 05, 2017 at 01:29:16PM +0100]:
> > I think that both of these activities are reasonable things to do.
> > They don't violate the self-containedness of Debian. If they are
> > technically forbidden by policy then policy should be changed. There
> > should be an exception saying that a package build may access the
> > Debian archive (and ideally it should specify how this should be
> > done.) If someone cares enough to document this situation then they
> > can file the bug against policy.
> > Of course it would be better if we had a more declarative way of
> > saying "this package needs foo.deb to build - and we mean the .deb,
> > not for foo to be installed", and the corresponding "this package
> > needs the source code for bar". But this is rather a niche, and it
> > doesn't seem to cause trouble in practice. So AFAICT it's no-one
> > priority.
> I am not convinced this use case should be supported - Even if the
> software providers are ourselves, which we trust not to trojan our own
> goodies, this still allows for a great deal of nondeterminism. If the
> "apt-get source"d package is updated, the build might not work anymore
> or might yield different results.
The source packages used should be tracked, and controlled, so that
the build can be reproduced. Actually doing that is probably a todo
list item but it seems essential to me.
I think there are already packages that do this. And (as discussed)
d-i does the same with .debs. We can use the same mechanism.
The point is not that Debian is a magical source of goodness here. It
is that _the place where the build-deps are being satisfied_ is a
magical place of goodness. It's just that our ways to handle
build-time-computed build-deps on uninstalled binaries, or on sources,
are not particularly mature.
Ian Jackson <email@example.com> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.