Hi,
Summary
=======
I've done some work in dak to improve the binary upload restrictions
that are currently in place to hopefully reduce some of the collateral
damage that resulted from the initial implementation. Binary upload
restrictions are now per-suite/component/architecture which means that
uploads to experimental and/or non-free should no longer be affected.
The current restrictions are listed below[1] for reference.
Why restrictions on binary uploads?
===================================
So there are several reasons why these restrictions have been put in
place:
(o) reproducibility
It's vitally important that packages in our archive can be rebuilt on
our buildds and not require a custom environment or source
modifications or other special treatment. When they can't, scaled
across as many packages and architectures as we have, it makes the job
of the security team nearly impossible.
The best (and IMO, only) pragmatic way of doing this is to actually
have built them on a real buildd.
(o) logging
The build logs at buildd.debian.org are invaluable in trying to debug
problematic builds. Byhand builds and other unofficial builds often
don't send an associated log to buildd.debian.org.
(o) build effort coordination
There's a reason the buildd suite is called 'wanna-build'. The core
of it, both when Roman first wrote it all those years ago and now, is
the sensible and efficient coordination of builds amongst multiple
build daemons. Having a random additional build daemon that's not
part of the 'wanna-build' system breaks this and all the advantages it
brings.
(o) emulated/cross-compiled buildd-ing considered potentially harmful
The idea of emulated buildds or cross compiling has been around for a
long time. Personally I don't think it's a good idea, but that's not
really the point. The point is that one person should not
unilaterally make the decision that they are or are not OK. If it's
the consensus of the release managers and the architecture porting
team that they want to use emulated buildds and/or cross compiling, I
absolutely will not stop them from doing so.
---
(Now if at this point, you're thinking about source only uploads,
please see [*].)
Why are the current set of restrictions in place?
=================================================
arm has had restrictions in place ever since Aurelien decided to
unilaterally turn on emulated buildd(s) for arm with no consensus from
the arm porting team or the release managers. This was problematic
for all the reasons listed above. Also, fundamentally, arm was not in
trouble release-wise because it lacked build power, but because it
lacked _humans_ willing and able to deal with the failing builds.
alpha has recently had restrictions added because the main alpha
buildd has been down due to relocation[2] for some time now and so, as
a result, the number of byhand builds on random machines has shot up.
Once Goedel is back (tomorrow - apparently) and if the byhand builds
stop, these restrictions could be relaxed.
--
James
[1]
################################################################################
Binary-Upload-Restrictions
{
Components
{
main;
contrib;
};
unstable
{
arm
{
9BF093BC475BABF8B6AEA5F6D7C3F131AB2A91F5;
70BC7F9D8C60D2265B7076A23760DBCFFD6645AB;
F849E2025D1C194DE62BC6C829BE5D2268FD549F;
};
alpha
{
9BF093BC475BABF8B6AEA5F6D7C3F131AB2A91F5;
70BC7F9D8C60D2265B7076A23760DBCFFD6645AB;
};
};
};
################################################################################
[2] Unfortunately there was very little notice of goedel's move and it
was originally scheduled only to take a couple of days but was
unavoidably delayed by external factors.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
[*]
Why not move to source only uploads?
====================================
A question that often comes up when this subject is discussed is 'hey,
I agree about the logging and reproducibility points above, so why not
move to source only uploads so you get those for all binaries?'
So, again, this is not something I personally think is a good idea but
I won't stand in the way of consensus of the Release Managers and the
developer community as a whole. I think it's a bad idea for two
reasons:
(a) we don't currently have the buildd infrastructure for this - it
would require a minimum of 2 (preferably 3) machines dedicated to
being i386 buildds. It would also make i386 uploads much more
sensitive to delays and really require better coverage than one
human could provide.
(b) source only uploads are in my experience very often badly tested
if they're even tested at all. For a long time after Ubuntu
switched to source only uploads, it was really obvious that a
large number of them hadn't even been test built, never mind
installed or used.[3][4]
We should probably fix (a) regardless, but the point is that it's not
where it needs to be right now. And maybe I'm wrong about how much
(b) would be a problem. *shrug* Just MO.
---
[3] And for some of these people the quality of their uploads was a
metric of their (paid) job performance...
[4] There are ways you can attempt to mitigate this (e.g. require
binaries but then throw them away), but when you do that, the
mindset is still that no one will use (-> you don't have to care
about) the binaries that are being uploaded.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
