Hi,
Looking at the original bug report, the history section seems
to detail implementation flaws in buildd's and dinstall, and the
major motivation for this proposal seems to ber a workaround for the
shortcomings of the dinstall+buildd system. I think this motivation
is bogus, we should be going to the root of the problem. Indeed, I
would oppose this motivation being given the weight of policy.
Then come the technical reasons. They are fuzzy -- while
supposedly not disallowing packages meant for unstable to be built on
a stable system, the techincal reasons go on and talk about how if
things are built on stable, then the libraries they are linked to
limits the lifetime of that particular binary (normal dependency
mechanisms shall take care of that for any future release), and
similar mumblings about potential future policy changes.
Indeed, if anything, the technical reasons make a case against
using helper packages, since helper packages may date the package's
policy compliance. And yet the proposal does not make helper packages
deprecated.
Indeed, there is little technically compelling about this
proposal, and just adds yet another bureaucratic hurdle for
developers to surpass.
manoj
--
The society which scorns excellence in plumbing as a humble activity
and tolerates shoddiness in philosophy because it is an exalted
activity will have neither good plumbing nor good
philosophy... neither its pipes nor its theories will hold water.
Manoj Srivastava <[EMAIL PROTECTED]> <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
