Re: Package checking
On Sun, Feb 25, 2001 at 12:32:06AM +, Julian Gilbey wrote: From current policy: When specifying the set of build-time dependencies, one should list only those packages explicitly required by the build. It is not necessary to list packages which are required merely because some other package in the list of build-time dependencies depends on them. The reason is that dependencies change, and you should list only those _you_ need. What others need is their business. When I asked a similar question some time ago, I did not find anything like this in the policy. I tried section 7.6 (Relationships between source and binary packages). Is the statement above new, or did I look in the wrong place? Jochen -- Omm (0)-(0) http://www.mathematik.uni-kl.de/~wwwstoch/voss/privat.html PGP signature
Re: Package checking
On Sun, Feb 25, 2001 at 12:32:06AM +, Julian Gilbey wrote: On Fri, Feb 23, 2001 at 11:16:16PM -0600, Sam TH wrote: $ lintian --version Lintian v1.20.6 $ lintian uf-view_1.2-2_i386.changes E: uf-view source: package-uses-debhelper-but-lacks-build-depends Fixed, I think. I removed every possibly related package I could find from my chroot, and then tried to build uf-view. I had to ask apt-get to install only: libgnome-dev, libghttp-dev and debhelper, but those brought in close to 50 other packages (all of X and GNOME, for example). Are those three all that is needed for Build-Depends? From current policy: When specifying the set of build-time dependencies, one should list only those packages explicitly required by the build. It is not necessary to list packages which are required merely because some other package in the list of build-time dependencies depends on them. The reason is that dependencies change, and you should list only those _you_ need. What others need is their business. Hopefully this will answer your question. Well, sort of. For the packe in question, it does. But say there was a package that depended on both GLib and GNOME (say, by including gnome.h and glib.h). If, at some later point, GNOME no longer depended on GLib, then just having Build-Depends: libgnome-dev would no longer be correct. But currently it is. What should one do in this situation? sam th [EMAIL PROTECTED] http://www.abisource.com/~sam/ GnuPG Key: http://www.abisource.com/~sam/key PGP signature
Re: Package checking
On Sun, 25 Feb 2001, Sam TH wrote: Well, sort of. For the packe in question, it does. But say there was a package that depended on both GLib and GNOME (say, by including If your package directly depends on another, declare it. The depends that are to be left 'implicit' are those of the packages you're depending on. -- "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: Package checking
On Sun, Feb 25, 2001 at 01:04:18PM +, Julian Gilbey wrote: On Sun, Feb 25, 2001 at 05:56:16AM -0600, Sam TH wrote: From current policy: When specifying the set of build-time dependencies, one should list only those packages explicitly required by the build. It is not necessary to list packages which are required merely because some other package in the list of build-time dependencies depends on them. The reason is that dependencies change, and you should list only those _you_ need. What others need is their business. Hopefully this will answer your question. Well, sort of. For the packe in question, it does. But say there was a package that depended on both GLib and GNOME (say, by including gnome.h and glib.h). If, at some later point, GNOME no longer depended on GLib, then just having Build-Depends: libgnome-dev would no longer be correct. But currently it is. What should one do in this situation? So if you need both gnome.h and glib.h, then you must Build-Depends: libgnome-dev, glib-dev, because these packages are both *explicitly* required by the build. Ok, that's what I expected. It just makes it harder to do the chroot-and-see-what-packages-you-need thing. Oh well. sam th [EMAIL PROTECTED] http://www.abisource.com/~sam/ GnuPG Key: http://www.abisource.com/~sam/key PGP signature
Re: dh_installdeb postrm
On Sun, Feb 25, 2001 at 01:14:57PM +, Julian Gilbey wrote:
On Sun, Feb 25, 2001 at 11:27:32PM +1100, Drew Parsons wrote:
Nice theory. But when I create meschach.postinst and meschach-dev.postint,
I find that meschach.postinst finds its way into the meschach-dev deb file!
This in spite of the fact that the ./debian directory has a meschach-dev
subdirectory containing meschach-dev.postint!
debian/ shouldn't have any subdirectories. Here's how it should go,
assuming that your source package is called meschach:
My apologies, I think I didn't explain myself properly. I have
meschach{-dev}.postinst and other files in ./debian. The meschach-dev
subdirectory I referred to is what gets creates by the build process (rather
then debian/tmp, which is created when there is only one package). Does that
sound right? meschach supplies the shared library, meschach-dev supplies
the developer files.
Drew
--
PGP public key available at http://dparsons.webjump.com/drewskey.txt
Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Policy and conffile editing
The 'edited by you or by a script line' which currently gets served up to users is apparently not quite in line with policy. It would probably be more appropriate to say somethine like 'The configuration file for this package has been modified since the package was installed' or something like that. I have over time observed a number of cases where I have to say Yes (install new version) for conf files I know I have never modified, either directly of with a helper configuration script, but I didn't report them as bugs because of the above message. Britton Kerin On Sat, Feb 24, 2001 at 02:19:08PM +0100, Ove Kaaven wrote: On Sat, 24 Feb 2001 [EMAIL PROTECTED] wrote: If you really think you want to change this automatically, you can ask the squid maintainer to remove /etc/squid.conf from his conffiles. If it's necessary to remove it from conffiles in order to edit it from a script in /usr/sbin, then both sgml-base (/etc/sgml/transitional.cat edited by install-sgmlcatalog) and mime-support (/etc/mailcap edited by update-mime) violates this policy. You're right. They should have bugs filed against them. Because otherwise, every time the package is upgraded, the sysadmin will be asked to check the changes unnecessarily. 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] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
keeping files from one version to the other.
Hi,
I'm in NM and I have adopted and packaged crafty, a chess engine.
Now, crafty keeps its opening books files in /var/lib/crafty and these files
are updated whenever a new position is played. Crafty 'learns' :-)
My problem is : when upgrading the package, the files in /var/lib/crafty are
overwritten by the original files coming with the new version package. How can
I preserve these files from being overwritten ? The files are normally
installed by debian/rules :
[eric@femto:~/debian/crafty-17.13]$ less debian/rules
[...]
install: build
dh_testdir
dh_testroot
dh_clean -k
dh_installdirs
# Add here commands to install the package into debian/tmp.
install -d debian/tmp
ln -sf ./crafty.6.gz \
debian/tmp/usr/share/man/man6/crafty.bin.6.gz
install -m2755 -o root -g games crafty debian/tmp/usr/games/crafty.bin
install crafty.wrapper debian/tmp/usr/games/crafty
install -m664 -o root -g games books.bin debian/tmp/var/lib/crafty
install -m664 -o root -g games book.{bin,lrn} debian/tmp/var/lib/crafty
install -m664 -o root -g games position.{bin,lrn}
debian/tmp/var/lib/crafty
install debian/doc/crafty.{faq,doc} debian/tmp/usr/share/doc/crafty
install debian/doc/read.me debian/tmp/usr/share/doc/crafty
install -m666 debian/crafty.rc debian/tmp/etc
[...]
Thanks.
--
Eric VAN BUGGENHAUT
[EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: /etc/ question
On Sun, Feb 25, 2001 at 09:34:19AM +, Julian Gilbey wrote: On Sun, Feb 25, 2001 at 05:15:37AM +0100, Eric Van Buggenhaut wrote: Remember to correctly unwind, moving the conffile back to its original place (as long as the original file does not exist) in the abort-install and abort-upgrade targets of preinst, postrm and postinst. [never tried this, but that seems to be what's needed from the not-so-clear policy chapter 6] In the package I maintain, called crafty, I moved /etc/craftyrc to /etc/crafty.rc and /var/cache/crafty to /var/lib/crafty in the previous version (17.9). Version now is 17.13. The 'move' routine is still in preinst of the latest version because we don't know what version people are upgrading from. Now that's my problem : if upgrade fails or is aborted, I should move the files back to their original location. But if people are upgrading from a 'post-move' version, the original location is different than if they were upgrading from a 'pre-move' location. So, where do I move the files back ??? Copy in the preinst, remove the old one in the postinst (with "configure" argument). That'll do the job. That's what I read in one of your previous message and it made sense to me. Then Henrique argued that it was a bad idea. On Sat, Feb 24, 2001 at 10:42:38PM -0300, Henrique M Holschuh wrote: On Sun, 25 Feb 2001, Julian Gilbey wrote: On Fri, Feb 23, 2001 at 03:57:33PM -0800, Sean 'Shaleh' Perry wrote: in your preinst, check for /etc/foo and if it exists, mkdir /etc/package and Perhaps better: copy it in the postinst, remove the old version in the postinst. Then if any problems arise, the original version will still be present. BAD idea. This will defeat the conffile change detection engine in dpkg, and will cause problems in some cases. Don't do that. Did he just say that because of the typo ? s/postinst/preinst ? Henrique ? 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/ -- Eric VAN BUGGENHAUT [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: /etc/ question
On Sun, 25 Feb 2001, Eric Van Buggenhaut wrote: Perhaps better: copy it in the postinst, remove the old version in the postinst. Then if any problems arise, the original version will still be present. BAD idea. This will defeat the conffile change detection engine in dpkg, and will cause problems in some cases. Don't do that. Did he just say that because of the typo ? s/postinst/preinst ? Yes. As long as the copy/move is done in preinst, it will not cause problems with the conffile handling by dpkg. -- "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: keeping files from one version to the other.
On Mon, Feb 26, 2001 at 01:29:00AM +0100, Eric Van Buggenhaut wrote:
My problem is : when upgrading the package, the files in /var/lib/crafty are
overwritten by the original files coming with the new version package. How can
I preserve these files from being overwritten ? The files are normally
installed by debian/rules :
[eric@femto:~/debian/crafty-17.13]$ less debian/rules
[...]
install: build
dh_testdir
dh_testroot
dh_clean -k
dh_installdirs
# Add here commands to install the package into debian/tmp.
install -d debian/tmp
ln -sf ./crafty.6.gz \
debian/tmp/usr/share/man/man6/crafty.bin.6.gz
install -m2755 -o root -g games crafty debian/tmp/usr/games/crafty.bin
install crafty.wrapper debian/tmp/usr/games/crafty
install -m664 -o root -g games books.bin debian/tmp/var/lib/crafty
install -m664 -o root -g games book.{bin,lrn} debian/tmp/var/lib/crafty
install -m664 -o root -g games position.{bin,lrn}
debian/tmp/var/lib/crafty
install debian/doc/crafty.{faq,doc} debian/tmp/usr/share/doc/crafty
install debian/doc/read.me debian/tmp/usr/share/doc/crafty
install -m666 debian/crafty.rc debian/tmp/etc
In the current crafty (17.13-3) these files are conffiles (look in
debian/conffiles or debian/crafty.conffiles), which means that they will only
overwrite the existing versions if they have not been modified or the user
requests it.
Cf: debian-policy and packaging-manual
--
- mdz
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: keeping files from one version to the other.
On Sun, Feb 25, 2001 at 09:26:55PM -0500, Matt Zimmerman wrote: In the current crafty (17.13-3) these files are conffiles (look in debian/conffiles or debian/crafty.conffiles), which means that they will only overwrite the existing versions if they have not been modified or the user requests it. and the user would be insane to request it... perhaps you should install them to doc/crafty/examples, and use postinst to check if they should be upgraded? if so, mv them to the proper location in /var. same thing is done for ppp's provider peer/chatscript files. Mike. -- Michael Beattie ([EMAIL PROTECTED]) - seeS hmm, anyone good with SQL here? elmo err.. sees.. we usually ask you :-/ - Debian GNU/Linux Ooohh You are missing out! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Still looking for a gnome-utils sponsor
Hi, I'm still looking for a sponsor for the gnome-utils package. My version is at http://www.mathematik.uni-kl.de/~wwwstoch/voss/gnome-utils/ If nobody volunteers, how could I increase the probability of finding a sponsor? Jochen -- Omm (0)-(0) http://www.mathematik.uni-kl.de/~wwwstoch/voss/privat.html pgp0rIL13zjeR.pgp Description: PGP signature
Re: Package checking
On Sun, Feb 25, 2001 at 12:32:06AM +, Julian Gilbey wrote: From current policy: When specifying the set of build-time dependencies, one should list only those packages explicitly required by the build. It is not necessary to list packages which are required merely because some other package in the list of build-time dependencies depends on them. The reason is that dependencies change, and you should list only those _you_ need. What others need is their business. When I asked a similar question some time ago, I did not find anything like this in the policy. I tried section 7.6 (Relationships between source and binary packages). Is the statement above new, or did I look in the wrong place? Jochen -- Omm (0)-(0) http://www.mathematik.uni-kl.de/~wwwstoch/voss/privat.html pgpKDJgcaR1lA.pgp Description: PGP signature
Re: Still looking for a gnome-utils sponsor
Ok, now I found someone. Adam McKenna [EMAIL PROTECTED] agreed to sponsor me. Thank you, Jochen -- Omm (0)-(0) http://www.mathematik.uni-kl.de/~wwwstoch/voss/privat.html pgpuwQI3QAXs8.pgp Description: PGP signature
Re: Package checking
On Sun, Feb 25, 2001 at 12:32:06AM +, Julian Gilbey wrote: On Fri, Feb 23, 2001 at 11:16:16PM -0600, Sam TH wrote: $ lintian --version Lintian v1.20.6 $ lintian uf-view_1.2-2_i386.changes E: uf-view source: package-uses-debhelper-but-lacks-build-depends Fixed, I think. I removed every possibly related package I could find from my chroot, and then tried to build uf-view. I had to ask apt-get to install only: libgnome-dev, libghttp-dev and debhelper, but those brought in close to 50 other packages (all of X and GNOME, for example). Are those three all that is needed for Build-Depends? From current policy: When specifying the set of build-time dependencies, one should list only those packages explicitly required by the build. It is not necessary to list packages which are required merely because some other package in the list of build-time dependencies depends on them. The reason is that dependencies change, and you should list only those _you_ need. What others need is their business. Hopefully this will answer your question. Well, sort of. For the packe in question, it does. But say there was a package that depended on both GLib and GNOME (say, by including gnome.h and glib.h). If, at some later point, GNOME no longer depended on GLib, then just having Build-Depends: libgnome-dev would no longer be correct. But currently it is. What should one do in this situation? sam th [EMAIL PROTECTED] http://www.abisource.com/~sam/ GnuPG Key: http://www.abisource.com/~sam/key pgpzHKFQohRO5.pgp Description: PGP signature
Re: Package checking
On Sun, 25 Feb 2001, Sam TH wrote: Well, sort of. For the packe in question, it does. But say there was a package that depended on both GLib and GNOME (say, by including If your package directly depends on another, declare it. The depends that are to be left 'implicit' are those of the packages you're depending on. -- 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 pgpa0ylB668gV.pgp Description: PGP signature
Re: dh_installdeb postrm
On Sat, Feb 24, 2001 at 01:22:03PM -0600, Gordon Sadler wrote:
Create files named debian/post{rm,inst} and debian/pre{rm,inst} if you
need to add specific code for one package. For multiple debs from same
source create debian/$package.post{rm,inst} debian/$package.pre{rm,inst}
Nice theory. But when I create meschach.postinst and meschach-dev.postint,
I find that meschach.postinst finds its way into the meschach-dev deb file!
This in spite of the fact that the ./debian directory has a meschach-dev
subdirectory containing meschach-dev.postint!
Weird, eh? And I'd really appreciate it if someone could help me understand
what the problem is likely to be.
Drew
--
PGP public key available at http://dparsons.webjump.com/drewskey.txt
Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A
Re: /etc/ question
On Sun, Feb 25, 2001 at 05:15:37AM +0100, Eric Van Buggenhaut wrote: Remember to correctly unwind, moving the conffile back to its original place (as long as the original file does not exist) in the abort-install and abort-upgrade targets of preinst, postrm and postinst. [never tried this, but that seems to be what's needed from the not-so-clear policy chapter 6] In the package I maintain, called crafty, I moved /etc/craftyrc to /etc/crafty.rc and /var/cache/crafty to /var/lib/crafty in the previous version (17.9). Version now is 17.13. The 'move' routine is still in preinst of the latest version because we don't know what version people are upgrading from. Now that's my problem : if upgrade fails or is aborted, I should move the files back to their original location. But if people are upgrading from a 'post-move' version, the original location is different than if they were upgrading from a 'pre-move' location. So, where do I move the files back ??? Copy in the preinst, remove the old one in the postinst (with configure argument). That'll do the job. 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: Package checking
On Sun, Feb 25, 2001 at 05:56:16AM -0600, Sam TH wrote: From current policy: When specifying the set of build-time dependencies, one should list only those packages explicitly required by the build. It is not necessary to list packages which are required merely because some other package in the list of build-time dependencies depends on them. The reason is that dependencies change, and you should list only those _you_ need. What others need is their business. Hopefully this will answer your question. Well, sort of. For the packe in question, it does. But say there was a package that depended on both GLib and GNOME (say, by including gnome.h and glib.h). If, at some later point, GNOME no longer depended on GLib, then just having Build-Depends: libgnome-dev would no longer be correct. But currently it is. What should one do in this situation? So if you need both gnome.h and glib.h, then you must Build-Depends: libgnome-dev, glib-dev, because these packages are both *explicitly* required by the build. 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: dh_installdeb postrm
On Sun, Feb 25, 2001 at 11:27:32PM +1100, Drew Parsons wrote:
Nice theory. But when I create meschach.postinst and meschach-dev.postint,
I find that meschach.postinst finds its way into the meschach-dev deb file!
This in spite of the fact that the ./debian directory has a meschach-dev
subdirectory containing meschach-dev.postint!
debian/ shouldn't have any subdirectories. Here's how it should go,
assuming that your source package is called meschach:
upstream:
meschach-1.2.3/meschach/...
/doc/...
/lib/...
/...
added:
meschach-1.2.3/debian/preinst
/postinst
/prerm
/docs
/examples
/meschach-dev.postinst
/meschach-dev.docs
And all of the the *{pre,post}{inst,rm} should have a #DEBHELPER# line
in them.
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: Package checking
On Sun, Feb 25, 2001 at 01:04:18PM +, Julian Gilbey wrote: On Sun, Feb 25, 2001 at 05:56:16AM -0600, Sam TH wrote: From current policy: When specifying the set of build-time dependencies, one should list only those packages explicitly required by the build. It is not necessary to list packages which are required merely because some other package in the list of build-time dependencies depends on them. The reason is that dependencies change, and you should list only those _you_ need. What others need is their business. Hopefully this will answer your question. Well, sort of. For the packe in question, it does. But say there was a package that depended on both GLib and GNOME (say, by including gnome.h and glib.h). If, at some later point, GNOME no longer depended on GLib, then just having Build-Depends: libgnome-dev would no longer be correct. But currently it is. What should one do in this situation? So if you need both gnome.h and glib.h, then you must Build-Depends: libgnome-dev, glib-dev, because these packages are both *explicitly* required by the build. Ok, that's what I expected. It just makes it harder to do the chroot-and-see-what-packages-you-need thing. Oh well. sam th [EMAIL PROTECTED] http://www.abisource.com/~sam/ GnuPG Key: http://www.abisource.com/~sam/key pgp3SGSXTg3ge.pgp Description: PGP signature
Re: Policy and conffile editing
The 'edited by you or by a script line' which currently gets served up to users is apparently not quite in line with policy. It would probably be more appropriate to say somethine like 'The configuration file for this package has been modified since the package was installed' or something like that. I have over time observed a number of cases where I have to say Yes (install new version) for conf files I know I have never modified, either directly of with a helper configuration script, but I didn't report them as bugs because of the above message. Britton Kerin On Sat, Feb 24, 2001 at 02:19:08PM +0100, Ove Kaaven wrote: On Sat, 24 Feb 2001 [EMAIL PROTECTED] wrote: If you really think you want to change this automatically, you can ask the squid maintainer to remove /etc/squid.conf from his conffiles. If it's necessary to remove it from conffiles in order to edit it from a script in /usr/sbin, then both sgml-base (/etc/sgml/transitional.cat edited by install-sgmlcatalog) and mime-support (/etc/mailcap edited by update-mime) violates this policy. You're right. They should have bugs filed against them. Because otherwise, every time the package is upgraded, the sysadmin will be asked to check the changes unnecessarily. 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]
keeping files from one version to the other.
Hi,
I'm in NM and I have adopted and packaged crafty, a chess engine.
Now, crafty keeps its opening books files in /var/lib/crafty and these files
are updated whenever a new position is played. Crafty 'learns' :-)
My problem is : when upgrading the package, the files in /var/lib/crafty are
overwritten by the original files coming with the new version package. How can
I preserve these files from being overwritten ? The files are normally
installed by debian/rules :
[EMAIL PROTECTED]:~/debian/crafty-17.13]$ less debian/rules
[...]
install: build
dh_testdir
dh_testroot
dh_clean -k
dh_installdirs
# Add here commands to install the package into debian/tmp.
install -d debian/tmp
ln -sf ./crafty.6.gz \
debian/tmp/usr/share/man/man6/crafty.bin.6.gz
install -m2755 -o root -g games crafty debian/tmp/usr/games/crafty.bin
install crafty.wrapper debian/tmp/usr/games/crafty
install -m664 -o root -g games books.bin debian/tmp/var/lib/crafty
install -m664 -o root -g games book.{bin,lrn} debian/tmp/var/lib/crafty
install -m664 -o root -g games position.{bin,lrn}
debian/tmp/var/lib/crafty
install debian/doc/crafty.{faq,doc} debian/tmp/usr/share/doc/crafty
install debian/doc/read.me debian/tmp/usr/share/doc/crafty
install -m666 debian/crafty.rc debian/tmp/etc
[...]
Thanks.
--
Eric VAN BUGGENHAUT
[EMAIL PROTECTED]
Re: /etc/ question
On Sun, Feb 25, 2001 at 09:34:19AM +, Julian Gilbey wrote: On Sun, Feb 25, 2001 at 05:15:37AM +0100, Eric Van Buggenhaut wrote: Remember to correctly unwind, moving the conffile back to its original place (as long as the original file does not exist) in the abort-install and abort-upgrade targets of preinst, postrm and postinst. [never tried this, but that seems to be what's needed from the not-so-clear policy chapter 6] In the package I maintain, called crafty, I moved /etc/craftyrc to /etc/crafty.rc and /var/cache/crafty to /var/lib/crafty in the previous version (17.9). Version now is 17.13. The 'move' routine is still in preinst of the latest version because we don't know what version people are upgrading from. Now that's my problem : if upgrade fails or is aborted, I should move the files back to their original location. But if people are upgrading from a 'post-move' version, the original location is different than if they were upgrading from a 'pre-move' location. So, where do I move the files back ??? Copy in the preinst, remove the old one in the postinst (with configure argument). That'll do the job. That's what I read in one of your previous message and it made sense to me. Then Henrique argued that it was a bad idea. On Sat, Feb 24, 2001 at 10:42:38PM -0300, Henrique M Holschuh wrote: On Sun, 25 Feb 2001, Julian Gilbey wrote: On Fri, Feb 23, 2001 at 03:57:33PM -0800, Sean 'Shaleh' Perry wrote: in your preinst, check for /etc/foo and if it exists, mkdir /etc/package and Perhaps better: copy it in the postinst, remove the old version in the postinst. Then if any problems arise, the original version will still be present. BAD idea. This will defeat the conffile change detection engine in dpkg, and will cause problems in some cases. Don't do that. Did he just say that because of the typo ? s/postinst/preinst ? Henrique ? 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/ -- Eric VAN BUGGENHAUT [EMAIL PROTECTED]
Re: /etc/ question
On Sun, 25 Feb 2001, Eric Van Buggenhaut wrote: Perhaps better: copy it in the postinst, remove the old version in the postinst. Then if any problems arise, the original version will still be present. BAD idea. This will defeat the conffile change detection engine in dpkg, and will cause problems in some cases. Don't do that. Did he just say that because of the typo ? s/postinst/preinst ? Yes. As long as the copy/move is done in preinst, it will not cause problems with the conffile handling by dpkg. -- 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 pgpnyMfyIIxPq.pgp Description: PGP signature
Re: keeping files from one version to the other.
On Mon, Feb 26, 2001 at 01:29:00AM +0100, Eric Van Buggenhaut wrote:
My problem is : when upgrading the package, the files in /var/lib/crafty are
overwritten by the original files coming with the new version package. How can
I preserve these files from being overwritten ? The files are normally
installed by debian/rules :
[EMAIL PROTECTED]:~/debian/crafty-17.13]$ less debian/rules
[...]
install: build
dh_testdir
dh_testroot
dh_clean -k
dh_installdirs
# Add here commands to install the package into debian/tmp.
install -d debian/tmp
ln -sf ./crafty.6.gz \
debian/tmp/usr/share/man/man6/crafty.bin.6.gz
install -m2755 -o root -g games crafty debian/tmp/usr/games/crafty.bin
install crafty.wrapper debian/tmp/usr/games/crafty
install -m664 -o root -g games books.bin debian/tmp/var/lib/crafty
install -m664 -o root -g games book.{bin,lrn}
debian/tmp/var/lib/crafty
install -m664 -o root -g games position.{bin,lrn}
debian/tmp/var/lib/crafty
install debian/doc/crafty.{faq,doc} debian/tmp/usr/share/doc/crafty
install debian/doc/read.me debian/tmp/usr/share/doc/crafty
install -m666 debian/crafty.rc debian/tmp/etc
In the current crafty (17.13-3) these files are conffiles (look in
debian/conffiles or debian/crafty.conffiles), which means that they will only
overwrite the existing versions if they have not been modified or the user
requests it.
Cf: debian-policy and packaging-manual
--
- mdz
Re: keeping files from one version to the other.
On Sun, Feb 25, 2001 at 09:26:55PM -0500, Matt Zimmerman wrote: In the current crafty (17.13-3) these files are conffiles (look in debian/conffiles or debian/crafty.conffiles), which means that they will only overwrite the existing versions if they have not been modified or the user requests it. and the user would be insane to request it... perhaps you should install them to doc/crafty/examples, and use postinst to check if they should be upgraded? if so, mv them to the proper location in /var. same thing is done for ppp's provider peer/chatscript files. Mike. -- Michael Beattie ([EMAIL PROTECTED]) - seeS hmm, anyone good with SQL here? elmo err.. sees.. we usually ask you :-/ - Debian GNU/Linux Ooohh You are missing out!
