[buildd-tools-devel] Bug#607945: Bug#607945: Bug#607945: Bug#607945: sbuild: can haz I entropy?

[Modestas Vainius]

Hello,

On ketvirtadienis 30 Gruodis 2010 20:33:48 Roger Leigh wrote:
> On Thu, Dec 30, 2010 at 07:24:20PM +0100, Cyril Brulebois wrote:
> > Roger Leigh <rleigh at codelibre.net> (30/12/2010):
> > > > Per host.  It's stored in /var/lib/sbuild/apt-keys .
> > > 
> > > Note that if there's a reason to do it per-chroot, we can do that.
> > > I couldn't envisage any security issues in sharing this key between
> > > chroots, but if there are it's a simple change.
> > 
> > Was just wondering whether this might make sense to move key creation
> > to sbuild's install time (openssh-server's style). Might be, if/when
> > the default resolver gets changed.
> > 
> > (“make sense” as in “can be thought of if it's per-host, and not if
> > it's per-chroot”; other considerations left aside.)
> 
> I did consider triggering this in the postinst.  I was concerned that
> this could break package installation on systems with scarce entropy
> by blocking package installation indefinitely.  Since this is currently
> an optional feature, I opted to allow generation when required.
> 
> After squeeze, I'd like to look at moving to the apt resolver (having
> more consistent/predicatable behaviour than aptitude). 

Oh, that's a myth with deep history apparently. Could you point me to a single 
case where (modern) aptitude resolver failed recently? With current safeguards 
in place, it should be very reliable and thanks to it, experimental is no 
longer a PITA making many people (including me) happy.

As long as apt-get does not consider dependencies from non-default sources, it 
won't be an option for non-unstable buildds. And apt-get resolver is not 
configurable at all (don't know about that new stuff in apt/experimental 
though).

P.S. This does not mean I advocate aptitude as default resolver. I'm just 
acting a role of mythbuster, someone has to :)

-- 
Modestas Vainius <modestas at vainius.eu>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.alioth.debian.org/pipermail/buildd-tools-devel/attachments/20110102/18eefe6c/attachment.pgp>