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

Re: Source only uploads?

On Fri, Oct 17, 2003 at 02:48:00PM +0100, Colin Watson wrote:
> On Fri, Oct 17, 2003 at 03:12:14PM +0200, Sven Luther wrote:
> > On Fri, Oct 17, 2003 at 02:53:48PM +0200, Wouter Verhelst wrote:
> > > Since experimental isn't autobuilt, I fail to see your point.
> > 
> > Well, try to install the quark 3.21-1 package on your system for example
> > then, and you will see what i mean.
> > 
> > I have XFree86 4.3.0 installed on my system, and i guess many other DD
> > have it or other experimental stuff installed, or self installed stuff,
> > or some older version of a library, or who knows what else.
> > 
> > When i uploaded quark 3.21-1, do you know what happened ? It brang with
> > it a xlibs (> 4.3.0) dependency, which naturally was not fullfillable in
> > sid or sarge. The packages was fine for all other architectures where it
> > was autobuilt.
> I have to say that you really should have noticed this. Before I sign
> and upload a package, I always use debc to read the control fields and
> debdiff to compare it with the previous version to make sure the changes
> are what I expected them to be. debdiff will show you changes in control
> fields in wdiff format, so changes in dependency versions are quite
> obvious. Frankly, I expect this or the equivalent to be the bare minimum
> any developer should do.

Well, sure, but why not automate these kind of things in order to let
less place to human mistakes ?

And the XFree86 dependencies are strange, i did an upgrade from xfree86
4.3.0-0pre1v1 to 4.3.0-0pre1v3, and then this started to happen, while
for other packages it didn't. I think it is higly time that 4.3.0 from
upstream reaches unstable finally.

But again, this is only one of the things that can go wrong, what if i
have an incompatible version of some library, or other selfbuilt stuff ? 

Sure, the ideal would be to rebuild everything in pbuilder, which is
what i try to do with xfree86 dependent packages now, but still, it is
placing the burden of it on all the individual developers, while a
centralized way to solve this problem would be easy to achieve, and cost
almost nothing in time. I had this discussion with some of the
ftp-master or debian-admin folk some time in the past, don't remember
exactly with whom or at which occasion, and they agreed with me that
this would be good idea to implement.

The build tools just mark something in the changes file to mark that the
package has been built, but dupload does not upload the binaries, even
if it check that they are present.

Then one of the autobuilders is modified to build its arch and arch:all
packages, and voila, we have reached one more level of security and
quality of our package, by eliminating the human error factor. Also we
diminish the bandwith requirement of the developers, which is maybe not
such a bad thing.

Sure, you will tell me that some may then fake the build on their
arches, or something such, but then the autobuilder will notice.

There could even be a two level autobuild process. Where one extra
machine will build the package for both arch: all and its arch, and
then, if it is sucessfull, all other packages build it or something.

Additionnaly, you have the added benefit of having a full build log of
all the packages in the archive, which is worth it.


Sven Luther

Reply to: