On Mon, Sep 12, 2005 at 01:44:14PM +0200, Christoph Berg wrote: > Re: Giuseppe Martino in <20050911130547.GA2325@mithrandir.dakordnet.org> > > >But what's more important. The build failed here: > > > > > >configure: error: cannot find install-sh or install.sh in config > > >./config > > >make: *** [config.status] Error 1 > > > > The problem is a missed Build-Depends aboud automake1.9. > > The proper way to fix that is to ship a bootstrapped .tar.bz2. Your > tarball does not build: > > $ ./configure > configure: error: cannot find install-sh or install.sh in config ./config Normally, these files should just be in the distribution tarball AFAIK. Such bootstrap scripts are used when getting the source from cvs (where you do not want generated files). > $ sh bootstrap > configure.ac: installing `config/install-sh' > configure.ac: installing `config/mkinstalldirs' > configure.ac: installing `config/missing' > Makefile.am: installing `./COPYING' > Makefile.am: installing `./INSTALL' > libaudiostream/Makefile.am: installing `config/depcomp' > > $ ./configure > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > [...] > > Please provide an updated upstream tarball. > > This will allow you to drop the build-dependency on the autotools, > which is considered evil by most people anyway. Huh? Looking at the output of bootstrap, it runs the autotools. Or do you mean it should be run before packaging the tarball? In any case, I strongly disagree that build-depending on autotools is wrong. The autotools were created to make platform-independant building possible on platforms with no special programs (such as the autotools) installed. However, if they _are_ available, then it's a good idea to regenerate all the files, because old versions of the autotools can have bugs (and it makes sure that the source files such as Makefile.am are actually the versions which produced the Makefile). It's a good idea to use the output from the newest autotools if possible, and on a Debian system that is easily possible, namely by build-depending on them. > Oh, and please ship real files in the tarball: > > lrwxrwxrwx 1 cb cb 31 2005-09-12 13:29 COPYING -> /usr/share/automake-1.9/COPYING > lrwxrwxrwx 1 cb cb 31 2005-09-12 13:29 INSTALL -> /usr/share/automake-1.9/INSTALL I agree that real files should be shipped in the tarball. However, to make sure the diff doesn't get too large, remove such files in the "clean" target (in debian/rules). > (Yes, having 1003951 copies of the GPL on your filesystem is a waste > of space, but that's the way it works.) No, it isn't. :-) The GPL should be in the source tarball (if the package is licensed under it), but you should not put it in the binary package. Instead, write in /usr/share/doc/<package>/copyright that it can be found in /usr/share/common-licenses/gpl. Since most people don't have many source packages installed, it's not a waste of user filesystem space, but only of archive filesystem space. Which is a much smaller problem. :-) > Re: Giuseppe Martino in <20050911184945.GA9831@mithrandir.dakordnet.org> > > > I have two things to say about this: > > > - debian/ should not be in the orig.tar.gz, but only in the diff.gz. See [1]. > > The .orig.tar.gz should be identical to the upstream tarball > (re-bz2-ipped in your case). It should, but as far as I understood it he was himself upstream, so he can change the upstream tarball. :-) If I understood it wrongly, he should urge his upstream to remove it, and just use it like this in the mean time. Thanks, Bas Wijnen -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://129.125.47.90/e-mail.html
Attachment:
signature.asc
Description: Digital signature