Re: Source only uploads?
Andrew Suffield wrote:
I understand your concern that a package must be able to built on
any Debian environment as long as the architecture is support and the
build-deps are respected, but I find that an additional request that
the package be able to build in pbuilder add to the quality of the
release.
At no point have I suggested that it should not have to build in an
artificial environment. What are you talking about?
I'm talking about ENSURING that the package is able to build in such
REPRODUCTIBLE environment and give consistent results. I remember
some packages which are even able to give a consistent source package
across rebuilds, which is pretty lame, IMHO.
I don't see how the current process help you on this? Any maintainer
can be lazy, and upload half-compiled package. There is many way to
make a package where even the debian/rules file doesn't run. If the
package is a binary-all, it will not even be notice!
If the maintainer is an incompetent moron, sure. But we generally
assume maintainers don't do stupid things like this.
Sorry, but I think error is human. And some upstream-source used
tricky passes and such errors can be produced. For example, must
people think that depending on xmltex is sufficient to process fo
file. xmltex is just the parser. You need passivetex, a set of
macros for fo-file to effectively process .fo file. If it happens
that the maintainer have passivetex install (because one of it's
other package used xmlto, which correctly depends on passivetex),
the package which correctly compile on his machine. More than that,
the odds that xmltex will only be call for binary-indep target is
great, since xmltex is mostly used to produce documentation.
For binary-all packages, people do on occasion attempt to rebuild them
to trap this sort of problem. It hasn't yet been automated, but it
could be.
It's the "people" and "on occasion" that tickle me here. Why not
replace it with "Debian" and "always" instead?
With the current process, most packages are built in a real-world
environment and then used in that environment by a significant number
of people, over a significant period of time. This gives us a better
than average chance of noticing any problems. It's not perfect, but
it's probably the best we're going to get.
I really fail to get your point: you said that a good maintainer will
always try to make it's package compile in a diversed environment and
that allowing source only upload will discourage such practice? What
kind of "good maintainer" is such? I really think that a good
maintainer will always try to do his best to ensure that's his package
will build correctly in any environment and platforms, at the best of
what his capacities (in term of knowledge, time and ressources) allow
him. Adding the capacity of source-only upload will just help him
ensure that his package can also be built into a "artificial" but
reproductible environment, which add to the QA of the package.
But now, if you said that a maintainer will bullshit a package and
make it only work in buildd environment, simply because he can only
upload source, you don't have a "good maintainer" anymore. In this
case, the amount of bullshit that can be upload, even with the current
process, is incredible. More than that, I don't see how the current
process can avoid such situation. With the source upload, you are sure
to be able to find at least one REPRODUCTIBLE configuration (even in a
real world situation) where the package can be built and give consistent
result with what's distributed.
Briefly, I failed to see how the status quo help with the problem you
described with the proposition.
Fabien
Reply to: