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. Friendly, Sven Luther
