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

Re: Debian doesn't have to be slower than time.



Quoting Colin Watson (cjwatson@debian.org):
> On Sun, Feb 17, 2002 at 06:05:40PM +0100, Michael Neuffer wrote:
> > 1. Packages should not only build on the maintainers machine
> >    but they should be able to compile in a "standard" environment
> >    to begin with.
> 
> One thing I've noticed is that packages sometimes do build in a standard
> environment, just subtly differently. This is both very hard to detect
> and very bad. Take one of my own packages, groff; it was OK when built
> on my machine (and the previous maintainer's machine, apparently) with
> lpr installed, but the -l option didn't work if lpr hadn't been
> installed on the build machine. How do you propose to detect this?

You probably can't beforehand, things like this will always pop up
unexpectedly, BUT at least there is a standard evironment that
is the same for all packages. Currently you can say that in first
approximation all packages are build in different environments.

However the problem that you mentioned is made even worse by
you uploading a package that you compiled in your environment,
because now the behaviour is different for the other architectures
that might or might not have lpd installed on the autobuilders..... 
 
> >    We can ensure this by forbidding binary uploads.
> 
> That encourages people not to test the packages they build, which is
> even worse. (In fact, it makes it *impossible* for them to test the
> exact .deb they've built prior to upload!)
> 
> A better idea might be to have a farm of build machines to which people
> could submit packages, get back the .deb, and test and upload that. I'm
> not fully convinced this is viable (encouraging people to build
> everything in sbuild and pbuilder is probably a better solution), but
> it's better than forbidding binary uploads.

I would prefer a different solution: The package is uploaded
source only, or the sources checked into a central source repository
and from there the packages are grabbed and build by build farms and put 
into a staging area.
The maintainer can download it from there, test it and withdraw it if
necessary. Otherwise it will be commited to incoming and normally 
processed.


> > Junichi Uekawa tried to rebuild the packages and already started 
> > filing bugs. With this automated he wouldn't have to do this menial,
> > tedious and and often unthankful task manually.
> 
> Packages often break when their build-dependencies change ...

Then you just do a "make world"..... 



Cheers
    Mike
-- 
People often think of research as a form of development -- that it's 
about doing exactly what you planned, doing it on time, and doing it 
with resources that you said you'd use.  But if you're going to do 
that, you have to know what you are doing, and if you know what you 
are doing, it isn't really research."
             --Dave Liddle, The New Yorker, Feb. 23/Mar.2, 1998, p84



Reply to: