Re: Bug#101325: lintian: empty (transition) packages shouldn't n
On Mon, Jun 18, 2001 at 06:24:52PM -0700, Sean 'Shaleh' Perry wrote: And how am I to tell a package that is empty on purpose from one created by accident? What constitutes empty? Maybe have a lintian warning about an empty package, but no error messages. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London Debian GNU/Linux Developer, see http://people.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: control file question
Hi Julian! The problem I have is that I have a library with same host architecture but different cross compilation targets, so I have things like: Build-Depends supports an arch specification, like: Build-Depends: libc-arm-version (=2.1) [arm] See policy section 7.1 for details. I know about that, but that doesn't help since it won't be compiled on that host architecture. It's for cross compiling, so for something like dietlibc-arm-dev you'll get Build-Depends that differ from dietlibc-dev on the _same_ host architecture. -- Regards Abraham I'm also against BODY-SURFING!! ___ Abraham vd Merwe [ZR1BBQ] - The Debian Project P.O. Box 3472, Matieland, Stellenbosch, 7602 Cell: +27 82 565 4451 Email: [EMAIL PROTECTED] Http: http://people.debian.org/~abz/ PGP signature
Re: control file question
On Tue, Jun 19, 2001 at 01:39:58PM +0200, Abraham vd Merwe wrote: Hi Julian! The problem I have is that I have a library with same host architecture but different cross compilation targets, so I have things like: Build-Depends supports an arch specification, like: Build-Depends: libc-arm-version (=2.1) [arm] See policy section 7.1 for details. I know about that, but that doesn't help since it won't be compiled on that host architecture. It's for cross compiling, so for something like dietlibc-arm-dev you'll get Build-Depends that differ from dietlibc-dev on the _same_ host architecture. But surely you can determine the packages needeed when dpkg-buildpackage is run on the various different architectures? I'm not sure I understand what the problem is. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London Debian GNU/Linux Developer, see http://people.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: removing old conffiles on upgrade
On Tue, Jun 19, 2001 at 05:54:25PM +0100, Muhammad Hussain Yusuf wrote: Hi, I've just changed the directories of the conffile, binaries etc. to conform with Policy 3.5.5.0. The old conffile dir was /etc/X11/filerunner and the new one is /etc/filerunner and the problem is that when installing new package, and an older version is installed, dpkg gives an error message, and the old conffile directory, not being empty, does not get removed. You could you copy the old version to the new in the preinst and remove the old version in the postinst. Yes, dpkg will warn that the old directory is not empty, but don't worry about it. But be careful to check the value of $1 and only to do them when the value is sensible (eg not when it's abort-*). Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London Debian GNU/Linux Developer, see http://people.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: removing old conffiles on upgrade
Em Tue, 19 Jun 2001 17:54:25 +0100 Muhammad Hussain Yusuf [EMAIL PROTECTED] escreveu: The old conffile dir was /etc/X11/filerunner and the new one is /etc/filerunner and the problem is that when installing new package, and an older version is installed, dpkg gives an error message, and the old conffile directory, not being empty, does not get removed. hm... I think that's the correct behavior, as long as it really removes the conffile, it should not remove the directory if it is not empty... doing an rm -rf on it can damage user-modified files... I'd not do that []s! -- Gustavo Noronha Silva - kov http://www.metainfo.org/kov ** | .''`. | Debian GNU/Linux: http://www.debian.org| | : :' : | Debian BR...: http://debian-br.sourceforge.net | | `. `'` | Be Happy! Be FREE! | | `-| Think globally, act locally! | ** -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: removing old conffiles on upgrade
On Tue, 19 Jun 2001, Steve M. Robbins wrote: What if you MOVED the file, rather than copying it: would dpkg still complain? Do it in preinst (and don't forget to add the proper error recovery to move it back should the install fail), and dpkg will not complain. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RE: Bug#101325: lintian: empty (transition) packages shouldn't n
On 19-Jun-2001 Julian Gilbey wrote: On Mon, Jun 18, 2001 at 06:24:52PM -0700, Sean 'Shaleh' Perry wrote: And how am I to tell a package that is empty on purpose from one created by accident? What constitutes empty? Maybe have a lintian warning about an empty package, but no error messages. while not opposed to this, it is definately non-trivial to implement, sorry all. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RE: Bug#101325: lintian: empty (transition) packages shouldn't n
On Mon, 18 Jun 2001, Sean 'Shaleh' Perry wrote: lintian complains about empty packages not having a copyright file. I think it should silently accept empty packages (Severity set to normal because it might actually stop packages from being installed). And how am I to tell a package that is empty on purpose from one created by accident? What constitutes empty? I think empty packages on purpose could be recognized by looking at whether another package from the same source conflicted with them. An empty package is one where data.tar.gz contains only ./. Simon -- GPG public key available from http://phobos.fs.tum.de/pgp/Simon.Richter.asc Fingerprint: DC26 EB8D 1F35 4F44 2934 7583 DBB6 F98D 9198 3292 Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!
Re: Depricating a library
Robert Bihlmeyer [EMAIL PROTECTED] immo vero scripsit If you want to provide further hints, upload a final version containing you can remove me without ill effects in the description. I think I would just remove the package, since the package has only entered unstable, and not on testing nor stable. On the other hand, if it had already entered testing or stable, things would have been slightly more complicated. regards, junichi -- [EMAIL PROTECTED] http://www.netfort.gr.jp/~dancer -BEGIN GEEK CODE BLOCK- Version: 3.12 GE d+ s:- a-- C+ UL P- L+++ E W++ N o-- K- w++ O- M- V-- PS+ PE-- Y+ PGP+ t-- 5 X-- R* tv- b+ DI- D++ G e h* r% !y+ --END GEEK CODE BLOCK--
Re: Bug#101325: lintian: empty (transition) packages shouldn't n
On Mon, Jun 18, 2001 at 06:24:52PM -0700, Sean 'Shaleh' Perry wrote: And how am I to tell a package that is empty on purpose from one created by accident? What constitutes empty? Maybe have a lintian warning about an empty package, but no error messages. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London Debian GNU/Linux Developer, see http://people.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/
control file question
Hi! Can I put a different Build-Depends for each binary package in a control file or can there only be a Build-Depends for the source package? The problem I have is that I have a library with same host architecture but different cross compilation targets, so I have things like: dietlibc-dev (same target as host) dietlibc-arm-dev (arm target, different host) dietlibc-powerpc-dev (powerpc target, different host) . . . The first one's Build-Depends is normal, but the rest also have cross compile suites as Build dependancies, e.g. the dietlibc-arm-dev Build-Depends would look like this: Build-Depends: debhelper ( 3.0.0), binutils-arm (= 2.9.5.0.12), gcc-arm (= 1:2.95.2-12e4), cpp-arm (= 1:2.95.2-12e4), libc6-dev-arm (= 2.1.3-8e4), task-cross-arm (= 0.2) Obviously putting all of these dependancies in the source package will result in a package which is virtually unbuildable on almost all systems out there. -- Regards Abraham Am I SHOPLIFTING? ___ Abraham vd Merwe [ZR1BBQ] - The Debian Project P.O. Box 3472, Matieland, Stellenbosch, 7602 Cell: +27 82 565 4451 Email: [EMAIL PROTECTED] Http: http://people.debian.org/~abz/ pgpeqxxRRsD1F.pgp Description: PGP signature
Re: control file question
On Tue, Jun 19, 2001 at 11:50:52AM +0200, Abraham vd Merwe wrote: Hi! Can I put a different Build-Depends for each binary package in a control file or can there only be a Build-Depends for the source package? You can only have one Build-Depends in the control file for the source package. The problem I have is that I have a library with same host architecture but different cross compilation targets, so I have things like: Build-Depends supports an arch specification, like: Build-Depends: libc-arm-version (=2.1) [arm] See policy section 7.1 for details. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London Debian GNU/Linux Developer, see http://people.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/
Re: control file question
Hi Julian! The problem I have is that I have a library with same host architecture but different cross compilation targets, so I have things like: Build-Depends supports an arch specification, like: Build-Depends: libc-arm-version (=2.1) [arm] See policy section 7.1 for details. I know about that, but that doesn't help since it won't be compiled on that host architecture. It's for cross compiling, so for something like dietlibc-arm-dev you'll get Build-Depends that differ from dietlibc-dev on the _same_ host architecture. -- Regards Abraham I'm also against BODY-SURFING!! ___ Abraham vd Merwe [ZR1BBQ] - The Debian Project P.O. Box 3472, Matieland, Stellenbosch, 7602 Cell: +27 82 565 4451 Email: [EMAIL PROTECTED] Http: http://people.debian.org/~abz/ pgpxMKSFsKnJr.pgp Description: PGP signature
Re: control file question
On Tue, Jun 19, 2001 at 01:39:58PM +0200, Abraham vd Merwe wrote: Hi Julian! The problem I have is that I have a library with same host architecture but different cross compilation targets, so I have things like: Build-Depends supports an arch specification, like: Build-Depends: libc-arm-version (=2.1) [arm] See policy section 7.1 for details. I know about that, but that doesn't help since it won't be compiled on that host architecture. It's for cross compiling, so for something like dietlibc-arm-dev you'll get Build-Depends that differ from dietlibc-dev on the _same_ host architecture. But surely you can determine the packages needeed when dpkg-buildpackage is run on the various different architectures? I'm not sure I understand what the problem is. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London Debian GNU/Linux Developer, see http://people.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/
removing old conffiles on upgrade
Hi, I've just changed the directories of the conffile, binaries etc. to conform with Policy 3.5.5.0. The old conffile dir was /etc/X11/filerunner and the new one is /etc/filerunner and the problem is that when installing new package, and an older version is installed, dpkg gives an error message, and the old conffile directory, not being empty, does not get removed. I've tried several things in prerm along the lines if [ $1 = upgrade ]; then rm -rf /etc/X11/filerunner fi but it does not work. Any help much appreciated. Regards Hussain
Re: removing old conffiles on upgrade
On Tue, Jun 19, 2001 at 05:54:25PM +0100, Muhammad Hussain Yusuf wrote: Hi, I've just changed the directories of the conffile, binaries etc. to conform with Policy 3.5.5.0. The old conffile dir was /etc/X11/filerunner and the new one is /etc/filerunner and the problem is that when installing new package, and an older version is installed, dpkg gives an error message, and the old conffile directory, not being empty, does not get removed. You could you copy the old version to the new in the preinst and remove the old version in the postinst. Yes, dpkg will warn that the old directory is not empty, but don't worry about it. But be careful to check the value of $1 and only to do them when the value is sensible (eg not when it's abort-*). Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London Debian GNU/Linux Developer, see http://people.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/
Re: removing old conffiles on upgrade
Em Tue, 19 Jun 2001 17:54:25 +0100 Muhammad Hussain Yusuf [EMAIL PROTECTED] escreveu: The old conffile dir was /etc/X11/filerunner and the new one is /etc/filerunner and the problem is that when installing new package, and an older version is installed, dpkg gives an error message, and the old conffile directory, not being empty, does not get removed. hm... I think that's the correct behavior, as long as it really removes the conffile, it should not remove the directory if it is not empty... doing an rm -rf on it can damage user-modified files... I'd not do that []s! -- Gustavo Noronha Silva - kov http://www.metainfo.org/kov ** | .''`. | Debian GNU/Linux: http://www.debian.org| | : :' : | Debian BR...: http://debian-br.sourceforge.net | | `. `'` | Be Happy! Be FREE! | | `-| Think globally, act locally! | **
Re: removing old conffiles on upgrade
On Tue, Jun 19, 2001 at 07:28:27PM +0100, Julian Gilbey wrote: On Tue, Jun 19, 2001 at 05:54:25PM +0100, Muhammad Hussain Yusuf wrote: Hi, I've just changed the directories of the conffile, binaries etc. to conform with Policy 3.5.5.0. The old conffile dir was /etc/X11/filerunner and the new one is /etc/filerunner and the problem is that when installing new package, and an older version is installed, dpkg gives an error message, and the old conffile directory, not being empty, does not get removed. You could you copy the old version to the new in the preinst and remove the old version in the postinst. Yes, dpkg will warn that the old directory is not empty, but don't worry about it. But be careful to check the value of $1 and only to do them when the value is sensible (eg not when it's abort-*). What if you MOVED the file, rather than copying it: would dpkg still complain? -S -- 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
Re: removing old conffiles on upgrade
On Tue, 19 Jun 2001, Steve M. Robbins wrote: What if you MOVED the file, rather than copying it: would dpkg still complain? Do it in preinst (and don't forget to add the proper error recovery to move it back should the install fail), and dpkg will not complain. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh
RE: Bug#101325: lintian: empty (transition) packages shouldn't n
On 19-Jun-2001 Julian Gilbey wrote: On Mon, Jun 18, 2001 at 06:24:52PM -0700, Sean 'Shaleh' Perry wrote: And how am I to tell a package that is empty on purpose from one created by accident? What constitutes empty? Maybe have a lintian warning about an empty package, but no error messages. while not opposed to this, it is definately non-trivial to implement, sorry all.
