[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [Caml-list] Release 3.09.1



On Fri, 2006-01-06 at 15:31 +0100, Sven Luther wrote:

> The less human intervention for drudge tasks the better, and it means human
> intervention can be focused on where it is really needed.

I think this is important, as anyone here already reading debian-mentors
would note ;(

How it is implemented is another issue, however it I believe this
is a Debian wide problem, not one restricted to ocaml-maint.

So if some acceptable solution is found for the working of 
ocaml-maint team, which is passing quality assurance processes
internally, but for which there is no Debian wide solution,
perhaps a note of this can be passed up: I would consider it
a small bug in Debian process if infrastructure needs to be
built like this by a maintainer to work around weaknesses
in the main Debian infrastructure .. and a very SERIOUS bug
if, after doing that, some processes to correct the problem
on a Debian wide scale is not initiated.

IMHO: if a build tool is upgraded in a way which is supposed
to build all previous sources .. not necessarily keeping the
binaries compatible .. then the rebuilding should be automatically
triggered directly by the autobuilder. There is no need for any
of the packages being built to be inspected by any maintainer
because they haven't changed.

If in fact some new errors occur then it is either

(a) the new tool is bugged
(b) the packaging of that tool *incorrectly* said that it 
was upwards compatible with respect to sources

and the tool packaging requires fixing.

The current technique used here is clearly very VERY bad
and entirely wrong. It prevents an end user rebuilding
from source and relying on the dependency checking to
rebuild the right things. If the autobuilder doesn't
do that the end user can't either.

In my view this entirely breaches the true Open Source
philosophy that behind the scenes everything is source,
and that the end user can rebuild from it at any time
to ensure that their binaries have not been tampered with.

[The archive of binaries provided by Debian should never
be directly addressed .. IMHO this is a very serious design
fault in the whole system. Instead those binaries should be
viewed entirely as a transparent cache. This isn't quite
the same issue as above, but they do seem related]

The failure of Debian to do this correctly has recently
resulted in a major disaster with ABI changes in C++ not
being correctly reflected .. leading to huge amounts of
unnecessary work. This should never happen again. Yet none
seem to recognize that the reason it happened was necessarily
due to a design fault in the Debian package management system.

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net



Reply to: