Re: debhelper "I have no package to build"
On Fri, May 17, 2002 at 10:01:14PM -0400, Steve M. Robbins wrote: > > The binary-common rule has lots of dh_* stuff there, including > dh_compress. I decided that compressing the HTML files would be a bad > idea, so I modified it to skip that one package using the dh_compress man page says: By default, dh_compress compresses files that debian pol icy mandates should be compressed, namely all files in usr/share/info, usr/share/man, usr/X11R6/man, files in usr/share/doc that are larger than 4k in size, (except the copyright file, .html files, and files that appear to be already compressed based on their extensions), and all changelog files. dh_compress contains the following snippet: (spacing changed) find usr/doc usr/share/doc -type f \\( -size +4k -or -name "changelog*" \\) \\ \\( -name changelog.html -or ! -iname "*.htm*" \ so i would venture to guess that the .html files are already skipped, and you need not do anything additional. -john -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
debhelper "I have no package to build"
Hi, I regularly use the template debian/rules file /usr/share/doc/debhelper/examples/rules.multi2 that has binary-indep and binary-arch rules that both use a single binary-common rule. The binary-common rule has lots of dh_* stuff there, including dh_compress. I decided that compressing the HTML files would be a bad idea, so I modified it to skip that one package using dh_compress -Nlibboost-doc However, the binary-indep rule sets DH_OPTIONS=-i before building binary-common meaning that there is *no* package for dh_compress to act upon when "binary-indep" is invoked. The build dies with the complaint of the subject line. After puzzling this out, I worked around the problem using dh_compress -Nlibboost-doc || true to ignore the error. Surely this is not the first time someone has run into this. Am I doing something silly? It seems a bit odd to make the "no package to build" diagnostic a fatal error. Thanks, -Steve P.S. Cc's appreciated, as I don't subscribe. -- by Rocket to the Moon, by Airplane to the Rocket, by Taxi to the Airport, by Frontdoor to the Taxi, by throwing back the blanket and laying down the legs ... - They Might Be Giants -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#146786: marked as done (debhelper: deb packages should contain SONAME)
Your message dated Fri, 17 May 2002 15:31:34 -0400 with message-id <[EMAIL PROTECTED]> and subject line Bug#146786: debhelper: deb packages should contain SONAME has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) -- Received: (at submit) by bugs.debian.org; 12 May 2002 23:16:18 + >From [EMAIL PROTECTED] Sun May 12 18:16:18 2002 Return-path: <[EMAIL PROTECTED]> Received: from mail5.svr.pol.co.uk [195.92.193.20] by master.debian.org with esmtp (Exim 3.12 1 (Debian)) id 1772Ze-0003A9-00; Sun, 12 May 2002 18:16:18 -0500 Received: from modem-355.babbelas.dialup.pol.co.uk ([62.25.133.99] helo=magicboy.superduper.net) by mail5.svr.pol.co.uk with esmtp (Exim 3.35 #1) id 1772ZZ-0004jz-00 for [EMAIL PROTECTED]; Mon, 13 May 2002 00:16:15 +0100 Received: from samc by magicboy.superduper.net with local (Exim 3.35 #1 (Debian)) id 1772ZW-00014N-00; Mon, 13 May 2002 00:16:10 +0100 From: Sam Clegg <[EMAIL PROTECTED]> Subject: debhelper: deb packages should contain SONAME To: [EMAIL PROTECTED] X-Mailer: bug 3.3.10.1 Message-Id: <[EMAIL PROTECTED]> Date: Mon, 13 May 2002 00:16:10 +0100 Delivered-To: [EMAIL PROTECTED] Package: debhelper Version: 4.0.2 Severity: wishlist Aren't dev packages supposed to contain the SONAME: libfoo0-dev (rather than libfoo-dev) And then: Conflicts: libfoo-dev Provides: libfoo-dev At least this is what the libpkg-guide says. -- System Information Debian Release: 3.0 Kernel Version: Linux magicboy 2.5.14 #1 Thu May 9 22:19:42 BST 2002 i686 unknown Versions of the packages debhelper depends on: ii binutils 2.12.90.0.1-4 The GNU assembler, linker and binary utiliti ii debconf-utils 1.0.32 debconf utilities ii dpkg-dev 1.9.20 Package building tools for Debian ii file 3.37-3.1 Determines file type using "magic" numbers ii fileutils 4.1-10 GNU file management utilities ii html2text 1.3.0.1-1 An advanced HTML to text converter. ii perl 5.6.1-7Larry Wall's Practical Extraction and Report --- Received: (at 146786-done) by bugs.debian.org; 17 May 2002 19:32:46 + >From [EMAIL PROTECTED] Fri May 17 14:32:46 2002 Return-path: <[EMAIL PROTECTED]> Received: from (kitenet.net) [208.27.22.224] (postfix) by master.debian.org with esmtp (Exim 3.12 1 (Debian)) id 178nT4-0005lZ-00; Fri, 17 May 2002 14:32:46 -0500 Received: by kitenet.net (Postfix, from userid 500) id C3823BC02F; Fri, 17 May 2002 15:31:34 -0400 (EDT) Date: Fri, 17 May 2002 15:31:34 -0400 From: Joey Hess <[EMAIL PROTECTED]> To: Sam Clegg <[EMAIL PROTECTED]>, [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: Bug#146786: debhelper: deb packages should contain SONAME Message-ID: <[EMAIL PROTECTED]> Reply-To: [EMAIL PROTECTED] References: <[EMAIL PROTECTED]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <[EMAIL PROTECTED]> User-Agent: Mutt/1.3.28i Delivered-To: [EMAIL PROTECTED] Sam Clegg wrote: > Aren't dev packages supposed to contain the SONAME: > > libfoo0-dev (rather than libfoo-dev) > > And then: > > Conflicts: libfoo-dev > Provides: libfoo-dev > > At least this is what the libpkg-guide says. Why is this bug report filed on debhelper, which merely uses whatever package names you give it? To answer your question, it is appropriate to use libfoo-dev as a package name if you intend to only ever support installing one version of a -dev package at a time. Since it's easy enough to work things out later if you change your mind (by introducing a libfoo2-dev), I'd recommend starting with libfoo-dev, but that is up to the discretion of the individual maintainer. See policy 11.3, paragraph 3. I don't know what this libpkg-guide is, but it needs to be fixed to not contradict policy. -- see shy jo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#146786: debhelper: deb packages should contain SONAME
Sam Clegg wrote: > Aren't dev packages supposed to contain the SONAME: > > libfoo0-dev (rather than libfoo-dev) > > And then: > > Conflicts: libfoo-dev > Provides: libfoo-dev > > At least this is what the libpkg-guide says. Why is this bug report filed on debhelper, which merely uses whatever package names you give it? To answer your question, it is appropriate to use libfoo-dev as a package name if you intend to only ever support installing one version of a -dev package at a time. Since it's easy enough to work things out later if you change your mind (by introducing a libfoo2-dev), I'd recommend starting with libfoo-dev, but that is up to the discretion of the individual maintainer. See policy 11.3, paragraph 3. I don't know what this libpkg-guide is, but it needs to be fixed to not contradict policy. -- see shy jo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Library package naming (and sponsor wanted)
Roger Leigh <[EMAIL PROTECTED]> immo vero scripsit: > I'm only parsing `debian/control.in' with sed, to add > `-$(UPSTREAM_VERSION)' suffixes to the library packages names, so that > they are always correctly versioned, so I can't see it causing > problems, since the parsing is done within debian/rules. I don't know, but it should probably be done in debian/rules clean target. I'd rather use objdump -p debian/tmp/usr/lib/libwhatever.so | grep SONAME than $(UPSTREAM_VERSION). regards, junichi -- [EMAIL PROTECTED] : Junichi Uekawa http://www.netfort.gr.jp/~dancer GPG Fingerprint : 17D6 120E 4455 1832 9423 7447 3059 BF92 CD37 56F4 Libpkg-guide: http://www.netfort.gr.jp/~dancer/column/libpkg-guide/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: handling file name conflict
W liście z czw, 16-05-2002, godz. 22:09, Robert Bihlmeyer pisze: > Alexandre <[EMAIL PROTECTED]> writes: > > > * having pyro and host conflict (but this annoys me since I need both > > packages on my machine) This is against Debian Policy. Look at http://bugs.debian.org/xnc for example of such bug. > Note that bind9-host also provides the "host" binary, but without the > "mx", "ns", "soa", etc. convenience symlinks (at least I guess they > are symlinks). I belive that host and bind9-host confilct BUT they ALSO provide the same functionality in /usr/bin/host, which as I understand here would NOT be the case here for ns. > > * renaming pyro's ns to, say 'pyro_ns', and changing all instances of > > 'ns' to 'pyro_ns' in the documentation and other programs > Viable solution, although I prefer "pyro-ns" for reasons of aesthetics > and typeability. First think if this is a binary that is to be used by ordinary user? If no, then put it into /usr/lib/pyro/ns or similar. If yes, I'd prefer ns-pyro or sth ns* like so that TAB completion would suggest the binary the user should use. > > * installing pyro's ns to another place than /usr/bin (without violating > > the Policy?) > If it really is a daemon and not usually executed by the user it may > go in /usr/sbin, or somewhere under /usr/libexec, or even /usr/share. It is at least not nice to have binaries with same name in *sbin* and *bin* directories. If user uses PATH (everyone uses!) then by executing it by root -> [/usr]/sbin/ns will be executed, while for ordinary user it'll be /usr/bin/ns. A mess :-/ > > * insisting heavily on the author so that he changes the name > Probably the best solution. Names of binaries that end up in the > path should be huffman coded (i.e. frequent usage => short name). This > program doesn't strike me as getting executed that often. Will your program (ns-pyro) be executed often? by many users? I belive that much more have host package installed. > Diverting (see dpkg-divert(8)) is also a possibility but I'm not sure > it is a good one. No idea about that, but sounds a bit like some hack. (will take a look at the manpage later). So what I'd do (and what I did in my packages): If it's binary for user - just change the name of binary in /usr/bin to /usr/bin/ns-pyro or sth. Other ideas that may come - keep originaly named binary somewhere in /usr/lib/pyro and modify PATH so that this dir were at the beginning if that can help here. - change all the source to call new binary If it's not a binary for ordinary user - put it in /usr/lib/pyro along with others which are not intended to be used widely use PATH or modify the source to get this working. HTH a bit Grzegorz Prokopski signature.asc Description: PGP signature
