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

Re: compiling packages



On Mon, Mar 05, 2001 at 08:12:50PM +0100, Robert Bihlmeyer wrote:
> Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de> writes:
> 
> > The list above is the list I am already caring about a lot.
> 
> Sure, my response was more to the first sentence "there is no strict
> policy" when indeed there's some semi-normative recipe in the DebDevRef.

Oh, ok. Sorry then. I meant there is no strict policy for how to distribute
the work on people interested in doing debian-hurd stuff. ;)

> > You can help everyone by submitting the bug you discover when testing it,
> > and avoid uploading such broken packages.
> 
> Sure, *if* you discover it. But I don't think it is reasonable to
> request that when someone ports a package depending on lots of
> libraries, that s/he should test every aspect of every recompiled
> library, especially if the facilities to test these are rather sparse.
> I'm content if the package itself sees basic testing.

Another misunderstanding. The level of testing I thought of was: Look at the
control file if the package dependencies look okay, try to install the
package and see if one of the binaries doesn't segfault at startup.

> > (What you describe works for the current Linux ports, and it will work for
> > us when we have catched up and have more eye-balls on the ftp archive.
> > Currently, where I have to put a lot of energy to get and keep the ftp
> > archive at least a bit consistent and usable, it doesn't.)
> 
> I'm talking about completely optional stuff like, say, gimp. Is it
> more work for you if we have a somewhat broken gimp package rather
> than none?

No, surely not. Again, I was more thinking of a completely broken zlib1g
package versus a working zlib1g package. I think we are thinking along the
same lines.

> I will now shut up until I have done some NMUs.

I hope you don't shut up. Your input on all issues is much appreciated. We
don't really disagree, we just imagined different cases. I should write up
some check ist for common build problems which are not easy to spot if you
don't know where to look for (most of this is related to libraries and
package dependencies, so not of concern for the standard stand alone
application with priority optional).

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann              GNU    http://www.gnu.org    marcus@gnu.org
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de



Reply to: