Re: alpine_1.0+dfsg-2_source.changes REJECTED
* Cyril Brulebois <cyril.brulebois@enst-bretagne.fr> [080112 14:38]:
> Well, no. A ???pure unstable environment??? on a development box can have
> various configuration tweaks, differing from the defaults shipped with
> the packages, and that can impact the built binaries.
Source packages are supposed to be also buildable by normal people which
should not need to setup any buildd environment for that. Thus packages
should work in any reasonable environment and give comparable results.
And at least I consider pure changes of configuration, different
programs choosen to supply a specific alternative and stuff like this
as reasonable environment changes. Things like having versions of stuff
installed not available in unstable or making changes to the system that
would also make normal packages depending on that no longer functional
are a other thing, though. But most systems go without such massive
tweaks.
> > and then arguing how stupid those reasons are. And for source only
> > uploads please take a look at Ubuntu. I really hope we do not want to
> > go that path and up with totally unuseable packages (in the sense of
> > can't possibly ever do the single thing that package is there for)
> > ending up in stable releases.
>
> I don't see how requesting to have a binary along the source package
> ensures it has been tested, that upgrades and transitions are OK, etc.
Having a binary available means the blame can be more certainly assigned
later. When there is a binary package and that is already misbuilt in
a way it cannot work, it is clear who is to blame. No "but here it
worked, the official buildd must do something a little bit different"
is possible.
> Having a single point of failure is i386-specific as far as I can tell.
> Testing migration suffered from that. Are you saying that redundancy is
> totally useless and that one should just not care about it?
Redundancy is good and important. But in the last time there was hardly
a point where i386 was effected by lack of it. More machines alone would
not have stopped a vacation of the one to sign to make some packages go
a bit slower. And even that (as nice at is was to shortly see some other
architectures being over i386 in the "architectures keeping up" graph
for a day or two) was a very isolated event that other architectures can
have quite often when some i386-assumptions in toolchain packages hit
another architecture hard.
Hochachtungsvoll,
Bernhard R. Link
Reply to: