Re: diversions
> That said, good luck with your package. Thanks for helping me. Wolfgang
Re: diversions
> You should contact them. Also, please understand one thing about diversions: > once you add one, you must keep the code to *remove* it around. Even if stop > doing a diversion, you will need to move the code to remove it from the *rm > scripts to the postinst script (to remove it on upgrades from old packages) > -- and you'll stay with that cruft in your postinst for as long as the > package is in Debian (or for two full Debian stable releases after the one > where the diversion was removed, whichever happens sooner). This doesn't scare me. But say I want to remove that diversion in the future but still keep the code to remove it. Won't it break the installation process whenever someone makes an update from a package that already did remove the diversion ? Actually the error could be ignored within the script: dpkg-divert --remove [blablabla] || echo No diversion, no worries. I have sent a message to the maintainers or lpr, lprng and cups. How much time do I have to wait before comitting my package ? W.
Re: diversions
> That said, good luck with your package. Thanks for helping me. Wolfgang -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: diversions
> You should contact them. Also, please understand one thing about diversions: > once you add one, you must keep the code to *remove* it around. Even if stop > doing a diversion, you will need to move the code to remove it from the *rm > scripts to the postinst script (to remove it on upgrades from old packages) > -- and you'll stay with that cruft in your postinst for as long as the > package is in Debian (or for two full Debian stable releases after the one > where the diversion was removed, whichever happens sooner). This doesn't scare me. But say I want to remove that diversion in the future but still keep the code to remove it. Won't it break the installation process whenever someone makes an update from a package that already did remove the diversion ? Actually the error could be ignored within the script: dpkg-divert --remove [blablabla] || echo No diversion, no worries. I have sent a message to the maintainers or lpr, lprng and cups. How much time do I have to wait before comitting my package ? W. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: diversions
On Sat, 05 May 2001, Colin Watson wrote: > Is this some kind of insurance against problems in the upgrade? When you Yes. I think most of the packages I've seen that use diversions do not remove them in prerm, but rather in postrm purge. I'm not sure¸ though. Still, as long as diversions are never left behind after a upgrade or purge, there is no problem. > The main situation where you need to be concerned about old versions of > your package is where you've previously made a mistake in the maintainer > scripts. Yes. -- "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 pgp33CpniCugO.pgp Description: PGP signature
Re: diversions
Henrique M Holschuh <[EMAIL PROTECTED]> wrote: >Also, please understand one thing about diversions: once you add one, >you must keep the code to *remove* it around. Even if stop doing a >diversion, you will need to move the code to remove it from the *rm >scripts to the postinst script (to remove it on upgrades from old >packages) -- and you'll stay with that cruft in your postinst for as >long as the package is in Debian (or for two full Debian stable >releases after the one where the diversion was removed, whichever >happens sooner). Is this some kind of insurance against problems in the upgrade? When you upgrade a package, the old package's prerm is run (with 'upgrade' as the first argument) before doing anything else, and the old postrm is also called somewhere along the line. Given that, it seems sensible to let the old version of the package worry about cleaning up after itself. The main situation where you need to be concerned about old versions of your package is where you've previously made a mistake in the maintainer scripts. -- Colin Watson [EMAIL PROTECTED]
Re: diversions
On Sat, 05 May 2001, Colin Watson wrote: > Is this some kind of insurance against problems in the upgrade? When you Yes. I think most of the packages I've seen that use diversions do not remove them in prerm, but rather in postrm purge. I'm not sure¸ though. Still, as long as diversions are never left behind after a upgrade or purge, there is no problem. > The main situation where you need to be concerned about old versions of > your package is where you've previously made a mistake in the maintainer > scripts. Yes. -- "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 PGP signature
Re: diversions
Henrique M Holschuh <[EMAIL PROTECTED]> wrote: >Also, please understand one thing about diversions: once you add one, >you must keep the code to *remove* it around. Even if stop doing a >diversion, you will need to move the code to remove it from the *rm >scripts to the postinst script (to remove it on upgrades from old >packages) -- and you'll stay with that cruft in your postinst for as >long as the package is in Debian (or for two full Debian stable >releases after the one where the diversion was removed, whichever >happens sooner). Is this some kind of insurance against problems in the upgrade? When you upgrade a package, the old package's prerm is run (with 'upgrade' as the first argument) before doing anything else, and the old postrm is also called somewhere along the line. Given that, it seems sensible to let the old version of the package worry about cleaning up after itself. The main situation where you need to be concerned about old versions of your package is where you've previously made a mistake in the maintainer scripts. -- Colin Watson [[EMAIL PROTECTED]] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: diversions
> Wouldn't it be a lot nicer to just add a "fax" entry to /etc/printcap? > I know that at least lprng can handle printing to pipes (I use it to > `print' mp3's to mpg123). I have already thought about that. But the problem is that this fax entry is supposed to spawn a graphical utility (requiring "DISPLAY to be set). And the standard lpr doesn't keep environment variables. The package I am writing is gfax. Wolfgang
Re: diversions
On Sat, 05 May 2001, Wolfgang Sourdeau wrote: > I am currently packaging gfax. In the Debian Policy it is specified > that one, willing to divert an executable, should contact the original > executable's maintainer. This is there mainly to make sure you damn well know what you're doing when playing with diversions, and to make sure other people that might affected by them are warned. AFAIK anyway. > In my case the lpr provided by gfax is a wrapper to provide the lpr > -Pfax command line. Should I contact both the LPRng and BSD lpr > managers ? Also, I would like to know why it should be done, so that I > can understand further. You should contact them. Also, please understand one thing about diversions: once you add one, you must keep the code to *remove* it around. Even if stop doing a diversion, you will need to move the code to remove it from the *rm scripts to the postinst script (to remove it on upgrades from old packages) -- and you'll stay with that cruft in your postinst for as long as the package is in Debian (or for two full Debian stable releases after the one where the diversion was removed, whichever happens sooner). That said, good luck with your package. -- "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 pgphJqZvDcx27.pgp Description: PGP signature
Re: diversions
Hi Wolfgang! You wrote: > In my case the lpr provided by gfax is a wrapper to provide the lpr > -Pfax command line. Should I contact both the LPRng and BSD lpr > managers ? Also, I would like to know why it should be done, so that I > can understand further. Wouldn't it be a lot nicer to just add a "fax" entry to /etc/printcap? I know that at least lprng can handle printing to pipes (I use it to `print' mp3's to mpg123). -- Kind regards, +---+ | Bas Zoetekouw | Si l'on sait exactement ce | || que l'on va faire, a quoi| | [EMAIL PROTECTED] | bon le faire?| |[EMAIL PROTECTED] | Pablo Picasso | +---+
Re: diversions
> Wouldn't it be a lot nicer to just add a "fax" entry to /etc/printcap? > I know that at least lprng can handle printing to pipes (I use it to > `print' mp3's to mpg123). I have already thought about that. But the problem is that this fax entry is supposed to spawn a graphical utility (requiring "DISPLAY to be set). And the standard lpr doesn't keep environment variables. The package I am writing is gfax. Wolfgang -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: diversions
On Sat, 05 May 2001, Wolfgang Sourdeau wrote: > I am currently packaging gfax. In the Debian Policy it is specified > that one, willing to divert an executable, should contact the original > executable's maintainer. This is there mainly to make sure you damn well know what you're doing when playing with diversions, and to make sure other people that might affected by them are warned. AFAIK anyway. > In my case the lpr provided by gfax is a wrapper to provide the lpr > -Pfax command line. Should I contact both the LPRng and BSD lpr > managers ? Also, I would like to know why it should be done, so that I > can understand further. You should contact them. Also, please understand one thing about diversions: once you add one, you must keep the code to *remove* it around. Even if stop doing a diversion, you will need to move the code to remove it from the *rm scripts to the postinst script (to remove it on upgrades from old packages) -- and you'll stay with that cruft in your postinst for as long as the package is in Debian (or for two full Debian stable releases after the one where the diversion was removed, whichever happens sooner). That said, good luck with your package. -- "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 PGP signature
Re: diversions
Hi Wolfgang! You wrote: > In my case the lpr provided by gfax is a wrapper to provide the lpr > -Pfax command line. Should I contact both the LPRng and BSD lpr > managers ? Also, I would like to know why it should be done, so that I > can understand further. Wouldn't it be a lot nicer to just add a "fax" entry to /etc/printcap? I know that at least lprng can handle printing to pipes (I use it to `print' mp3's to mpg123). -- Kind regards, +---+ | Bas Zoetekouw | Si l'on sait exactement ce | || que l'on va faire, a quoi| | [EMAIL PROTECTED] | bon le faire?| |[EMAIL PROTECTED] | Pablo Picasso | +---+ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: diversions!? arrrgghhh!!!!
Marcelo E. Magallon wrote: > Preparing to replace wmaker 0.20.3-1 (using wmaker_0.20.3-3.deb) ... > Removing diversion of asclock.1x to asclock.afterstep.1x... > dpkg-divert: rename involves overwriting > `/usr/X11R6/man/man1/asclock.1x.gz' with >different file `/usr/X11R6/man/man1/asclock.afterstep.1x.gz', not allowed > dpkg: error processing wmaker_0.20.3-3.deb (--unpack): > subprocess pre-installation script returned error exit status 2 > > The offending command in preinst: > > dpkg-divert --quiet --package wmaker \ > --divert $old_asclock_man_divert_to \ > --remove $asclock_man > > Please note it doesn't contain --rename > > Now, WHAT THE HECK IS dpkg-divert TALKING ABOUT THEN!!!??!??!?! It sounds like it's renaming "asclock.afterstep.1x" _back_ to "asclock.1x", since you told it to undo the diversion. I've just looked at the source code, the error is from the checkrename() function, which is indeed called when you remove a diversion, right before it does a dorename() to undo the diversion. So it's just a crappy error message. It might be interesting to look at dpkg-divert --list on the affected systems. > Any ideas about how I can handle this? Sorry I can't shed any more light. This reminds me of the snafu last spring with xaw-wrappers and dpkg-divert; took about 2 months to fix it and I still can't entirely wrap my head around what was wrong. Hang in there.. dpkg-divert is a beast. -- see shy jo
Re: Diversions example?
Mitch Blevins wrote: > Will someone please point me to a package that has a good example > of diversions. I am assuming that this is what I need to package > gnumaniac, which replaces the outdated man pages in the *-utils > gnu packages. Jein. I understand that dpkg-divert is only a workaround. Generally speaking it would be better if both packages would agree and use the alternatives mechanism to do so. Anyway, adding diversions is not difficult, issue dpkg-divert with or without -h or --help and you'll experience a very easy syntax. Packages using diversions are dpkg-multicd and file-rc. Please think about it and issue 'grep dpkg-divert /var/lib/dpkg/info/*" to find more packages using diversions. Regards, Joey -- If you come from outside of Finland, you live in wrong country. -- motd of irc.funet.fi Please always Cc to me when replying to me on the lists.
