Bug#656997: libogre-1.7.3: Unmodified /etc/OGRE/plugins.cfg not removed on upgrade
On Thu, 2012-02-16 at 23:58 +, Manuel A. Fernandez Montecelo wrote: 2012/2/8 Manuel A. Fernandez Montecelo manuel.montez...@gmail.com: Does this make sense and covers all cases, except the c) one? It's implemented in the current repository, can you please check this one? Should work with git-buildpackage directly. http://anonscm.debian.org/gitweb/?p=pkg-games/ogre.git;a=summary Can you please test this (or otherwise let me know if you can't)? I was planning to upload a new version ASAP to try to fix this one, but also other issues, and don't want to delay that too much. Cheers. I should be able to give this a test tomorrow. I'll let you know either way. :) -- Sam Morris https://robots.org.uk/ 3412 EA18 1277 354B 991B C869 B219 7FDB 5EA0 1078 signature.asc Description: This is a digitally signed message part
Bug#656997: libogre-1.7.3: Unmodified /etc/OGRE/plugins.cfg not removed on upgrade
2012/2/17 Sam Morris s...@robots.org.uk: After installing the 1.7.4-1 debs, I was left with: /etc/OGRE-1.7.3 (empty directory) /etc/OGRE/plugins.cfg.dpkg-remove [...] Without a dummy libogre-1.7.3 package that would exist solely to call rm_conffile in its postinst, perhaps we could solve this by having libogre-1.7.3's postinst script run rm -f /etc/OGRE/plugins.cfg.dpkg-remove... if the file doesn't exist then there is no side effect, and if it does then the user would already have had to remove libogre-1.7.3 because libogre-1.7.4 conflicts with it. OK. But I guess that /etc/OGRE-1.7.3 should be removed as well, if it's empty? Thank you very much for your help again. Cheers. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#656997: libogre-1.7.3: Unmodified /etc/OGRE/plugins.cfg not removed on upgrade
On Fri, 2012-02-17 at 15:59 +, Manuel A. Fernandez Montecelo wrote: 2012/2/17 Sam Morris s...@robots.org.uk: After installing the 1.7.4-1 debs, I was left with: /etc/OGRE-1.7.3 (empty directory) /etc/OGRE/plugins.cfg.dpkg-remove [...] Without a dummy libogre-1.7.3 package that would exist solely to call rm_conffile in its postinst, perhaps we could solve this by having libogre-1.7.3's postinst script run rm -f /etc/OGRE/plugins.cfg.dpkg-remove... if the file doesn't exist then there is no side effect, and if it does then the user would already have had to remove libogre-1.7.3 because libogre-1.7.4 conflicts with it. OK. But I guess that /etc/OGRE-1.7.3 should be removed as well, if it's empty? Oh yeah, I forgot to suggest that! :) Thank you very much for your help again. Cheers. You're welcome! Let me know if you want me to test anything else--I've still got my build server that had my locally modified package installed. I see you're using the ~ trick when invoking rm_conffiles now so I can either test the package in git to see what happens, or wait to test that + the final removal of libogre-1.3.7's config file. Regards, -- Sam Morris s...@robots.org.uk -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#656997: libogre-1.7.3: Unmodified /etc/OGRE/plugins.cfg not removed on upgrade
2012/2/17 Sam Morris s...@robots.org.uk: On Fri, 2012-02-17 at 15:59 +, Manuel A. Fernandez Montecelo wrote: 2012/2/17 Sam Morris s...@robots.org.uk: After installing the 1.7.4-1 debs, I was left with: /etc/OGRE-1.7.3 (empty directory) /etc/OGRE/plugins.cfg.dpkg-remove [...] Without a dummy libogre-1.7.3 package that would exist solely to call rm_conffile in its postinst, perhaps we could solve this by having libogre-1.7.3's postinst script run rm -f /etc/OGRE/plugins.cfg.dpkg-remove... if the file doesn't exist then there is no side effect, and if it does then the user would already have had to remove libogre-1.7.3 because libogre-1.7.4 conflicts with it. OK. But I guess that /etc/OGRE-1.7.3 should be removed as well, if it's empty? Oh yeah, I forgot to suggest that! :) So how does this look? http://anonscm.debian.org/gitweb/?p=pkg-games/ogre.git;a=commitdiff;h=3100a17c9b2aa5f1e7105707ed70c2f541066528 (Note that .postinst and .postrm are symlinks to the .preinst file). You're welcome! Let me know if you want me to test anything else--I've still got my build server that had my locally modified package installed. I see you're using the ~ trick when invoking rm_conffiles now so I can either test the package in git to see what happens, or wait to test that + the final removal of libogre-1.3.7's config file. I think that it's fine if you wait for the final version, if you don't want to bother. The changes are quite straightforward. Cheers. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#656997: libogre-1.7.3: Unmodified /etc/OGRE/plugins.cfg not removed on upgrade
2012/2/8 Manuel A. Fernandez Montecelo manuel.montez...@gmail.com: Does this make sense and covers all cases, except the c) one? It's implemented in the current repository, can you please check this one? Should work with git-buildpackage directly. http://anonscm.debian.org/gitweb/?p=pkg-games/ogre.git;a=summary Can you please test this (or otherwise let me know if you can't)? I was planning to upload a new version ASAP to try to fix this one, but also other issues, and don't want to delay that too much. Cheers. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#656997: libogre-1.7.3: Unmodified /etc/OGRE/plugins.cfg not removed on upgrade
2012/2/7 Sam Morris s...@robots.org.uk:
No problem. I looked into the conffile issue a bit further and I think
that the dpkg-maintscript documentation needs to be changed. I filed
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=658854 where you can
find a brief description of the issue; in summary, I think you should
set the 'lastversion' to 1.7.3-7~ in the next revision of the package
(assuming that the next revision will be 1.7.3-7 of course). The
existing documentation would suggest you use 1.7.3-6, but this causes
the conffile removal code to be skipped in the case of a user rebuilding
the package with a local version number: the user would be upgrading
from 1.7.3-6local1, which is greater than 1.7.3-6 and therefore
rm_conffile thinks that it doesn't need to do anything. Any possible
(sane) local version number is guaranteed to be 1.7.3-7~ however, and
so that version number is safe to use when invoking rm_conffile.
Actually, I'm creating a new upstream package (1.7.4-1) because it was
released in mid January.
Yesterday when past midnight I gave up when testing this, because with
my tests I get the file renamed and backed up sometimes, e.g. when
using the file from -4 or so (cannot recall the actual details). In
-5 the paths within the plugins.cfg had to be changed because of
multi-archi-fying, and in -6 the file moved to /etc/OGRE-VERSION/ to
make possible to install different versions of OGRE at once. A bit of
a mess, yes, and ultimately to remove the file altogether.
Maybe the helper assumes that you've installed each and every version
and just compares with the md5sum of the last version used?
I'm using this right now:
---
$ cat debian/libogre-VERSION.preinst
#!/bin/sh -e
if dpkg-maintscript-helper supports rm_conffile 2/dev/null; then
dpkg-maintscript-helper rm_conffile /etc/OGRE/plugins.cfg 1.7.4-1
libogre-1.7.3 -- $@
dpkg-maintscript-helper rm_conffile /etc/OGRE-1.7.3/plugins.cfg
1.7.4-1 libogre-1.7.3 -- $@
fi
$ md5sum debian/libogre-VERSION.{preinst,postinst,postrm}
9dc129ad3931e9a550ca9f65f7ee800e debian/libogre-VERSION.preinst
9dc129ad3931e9a550ca9f65f7ee800e debian/libogre-VERSION.postinst
9dc129ad3931e9a550ca9f65f7ee800e debian/libogre-VERSION.postrm
---
So I will need to test all of the possible combinations to try to
understand it and fix it for good this time.
BTW, I moved the packaging to:
http://anonscm.debian.org/gitweb/?p=pkg-games/ogre.git;a=summary
I have to synchronise last changes from yesterday (will try to do it
within the next hours), but maybe you find it helpful.
Cheers.
PS: are you trying to backport the package or something?
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#656997: libogre-1.7.3: Unmodified /etc/OGRE/plugins.cfg not removed on upgrade
On Tue, 2012-02-07 at 09:39 +, Manuel A. Fernandez Montecelo wrote:
2012/2/7 Sam Morris s...@robots.org.uk:
No problem. I looked into the conffile issue a bit further and I think
that the dpkg-maintscript documentation needs to be changed. I filed
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=658854 where you can
find a brief description of the issue; in summary, I think you should
set the 'lastversion' to 1.7.3-7~ in the next revision of the package
(assuming that the next revision will be 1.7.3-7 of course). The
existing documentation would suggest you use 1.7.3-6, but this causes
the conffile removal code to be skipped in the case of a user rebuilding
the package with a local version number: the user would be upgrading
from 1.7.3-6local1, which is greater than 1.7.3-6 and therefore
rm_conffile thinks that it doesn't need to do anything. Any possible
(sane) local version number is guaranteed to be 1.7.3-7~ however, and
so that version number is safe to use when invoking rm_conffile.
Actually, I'm creating a new upstream package (1.7.4-1) because it was
released in mid January.
Ok, then I suggest 1.7.4-1~ when invoking dpkg-maintscript-helper.
Yesterday when past midnight I gave up when testing this, because with
my tests I get the file renamed and backed up sometimes, e.g. when
using the file from -4 or so (cannot recall the actual details). In
-5 the paths within the plugins.cfg had to be changed because of
multi-archi-fying, and in -6 the file moved to /etc/OGRE-VERSION/ to
make possible to install different versions of OGRE at once. A bit of
a mess, yes, and ultimately to remove the file altogether.
Maybe the helper assumes that you've installed each and every version
and just compares with the md5sum of the last version used?
The version check is just there so that the code for removing/renaming a
conffile is only run once. The problem I ran into is that I'd rebuilt
the package, bumping the version number past that which the new
package's maintainer scripts invoked rm_conffile with. Hence the bug I
filed on dpkg to get the documentation sorted out. Then will come
lintian checks, perhaps... :)
I'm using this right now:
---
$ cat debian/libogre-VERSION.preinst
#!/bin/sh -e
if dpkg-maintscript-helper supports rm_conffile 2/dev/null; then
dpkg-maintscript-helper rm_conffile /etc/OGRE/plugins.cfg 1.7.4-1
libogre-1.7.3 -- $@
dpkg-maintscript-helper rm_conffile /etc/OGRE-1.7.3/plugins.cfg 1.7.4-1
libogre-1.7.3 -- $@
fi
$ md5sum debian/libogre-VERSION.{preinst,postinst,postrm}
9dc129ad3931e9a550ca9f65f7ee800e debian/libogre-VERSION.preinst
9dc129ad3931e9a550ca9f65f7ee800e debian/libogre-VERSION.postinst
9dc129ad3931e9a550ca9f65f7ee800e debian/libogre-VERSION.postrm
---
That looks fine to me (though the version number should be changed).
So I will need to test all of the possible combinations to try to
understand it and fix it for good this time.
BTW, I moved the packaging to:
http://anonscm.debian.org/gitweb/?p=pkg-games/ogre.git;a=summary
I have to synchronise last changes from yesterday (will try to do it
within the next hours), but maybe you find it helpful.
Great. I'll test this and let you know what happens.
Cheers.
PS: are you trying to backport the package or something?
Yeah, just for my own build servers. We need to use Boost 1.48 hence I
rebuild the package.
--
Sam Morris s...@robots.org.uk
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#656997: libogre-1.7.3: Unmodified /etc/OGRE/plugins.cfg not removed on upgrade
2012/2/7 Sam Morris s...@robots.org.uk: The version check is just there so that the code for removing/renaming a conffile is only run once. So I still don't understand it very well how it works. I uninstall all libogre-*, then remove /etc/OGRE*, as if nothing was ever installed. Then I install -3, and: -- # find /etc/OGRE* -type f; echo; tail -n 100 /etc/OGRE*/* /etc/OGRE/plugins.cfg # /etc/OGRE/plugins.cfg - ogre plugins installed on Debian systems # # Warning: this file is autogenerated but anything between this line and # the line saying -*- ogre-plugins -*- will be copied as-is on updates. PluginFolder=/usr/lib/OGRE # default plugins installed with the libogremain package. Plugin=Plugin_BSPSceneManager.so Plugin=Plugin_OctreeSceneManager.so Plugin=Plugin_OctreeZone.so Plugin=Plugin_ParticleFX.so Plugin=RenderSystem_GL.so Plugin=Plugin_PCZSceneManager.so # Don't edit anything starting from next line; it was autogenerated. # -*- ogre-plugins -*- [Please, don't remove or modify this marker] -- When I then upgrade to -6, the current in unstable and without config file, that's what happens: -- Preparing to replace libogre-1.7.3 1.7.3-3 (using .../libogre-1.7.3_1.7.3-6_amd64.deb) ... Moving obsolete conffile /etc/OGRE/plugins.cfg out of the way... Unpacking replacement libogre-1.7.3 ... dpkg: warning: unable to delete old directory '/etc/OGRE': Directory not empty Processing triggers for man-db ... (Reading database ... 111898 files and directories currently installed.) Removing libboost-thread1.46.1 ... Purging configuration files for libboost-thread1.46.1 ... Setting up libogre-1.7.3 (1.7.3-6) ... -- Now the config files are (notice that it's been renamed to .dpkg-remove, but not removed (probably because of the missing .postrm counterpart): -- # find /etc/OGRE* -type f; echo; tail -n 100 /etc/OGRE*/* /etc/OGRE/plugins.cfg.dpkg-remove # /etc/OGRE/plugins.cfg - ogre plugins installed on Debian systems # [... same content as the previous one ...] -- Now, if I install 1.7.4-1, since it doesn't conflict with any other version of the library (I removed Breaks/Replaces, since it's an undesired feature, and if the files are not installed in the same path is not a problem), it cannot go wild and remove other binary package's config files. For one, the libogre-1.7.3 can continue to be installed when 1.7.4 is installed, 1.7.4 shouldn't remove it. And I don't know if because of this reason or because of the package name changed, when libogre-1.7.4 is removed but .3-3 (one of the versions still shipping /etc/OGRE/plugins.cfg) still installed, the file continues there. When I remove .3-3, the /etc/OGRE/plugins.cfg (unmodified) goes away. So I'm starting to get out of ideas about how to solve this. Cheers. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#656997: libogre-1.7.3: Unmodified /etc/OGRE/plugins.cfg not removed on upgrade
On Tue, 2012-02-07 at 15:07 +, Manuel A. Fernandez Montecelo wrote: 2012/2/7 Sam Morris s...@robots.org.uk: The version check is just there so that the code for removing/renaming a conffile is only run once. So I still don't understand it very well how it works. I uninstall all libogre-*, then remove /etc/OGRE*, as if nothing was ever installed. Then I install -3, and: -- # find /etc/OGRE* -type f; echo; tail -n 100 /etc/OGRE*/* /etc/OGRE/plugins.cfg # /etc/OGRE/plugins.cfg - ogre plugins installed on Debian systems # # Warning: this file is autogenerated but anything between this line and # the line saying -*- ogre-plugins -*- will be copied as-is on updates. PluginFolder=/usr/lib/OGRE # default plugins installed with the libogremain package. Plugin=Plugin_BSPSceneManager.so Plugin=Plugin_OctreeSceneManager.so Plugin=Plugin_OctreeZone.so Plugin=Plugin_ParticleFX.so Plugin=RenderSystem_GL.so Plugin=Plugin_PCZSceneManager.so # Don't edit anything starting from next line; it was autogenerated. # -*- ogre-plugins -*- [Please, don't remove or modify this marker] -- When I then upgrade to -6, the current in unstable and without config file, that's what happens: -- Preparing to replace libogre-1.7.3 1.7.3-3 (using .../libogre-1.7.3_1.7.3-6_amd64.deb) ... Moving obsolete conffile /etc/OGRE/plugins.cfg out of the way... Unpacking replacement libogre-1.7.3 ... dpkg: warning: unable to delete old directory '/etc/OGRE': Directory not empty Processing triggers for man-db ... (Reading database ... 111898 files and directories currently installed.) Removing libboost-thread1.46.1 ... Purging configuration files for libboost-thread1.46.1 ... Setting up libogre-1.7.3 (1.7.3-6) ... -- Now the config files are (notice that it's been renamed to .dpkg-remove, but not removed (probably because of the missing .postrm counterpart): -- # find /etc/OGRE* -type f; echo; tail -n 100 /etc/OGRE*/* /etc/OGRE/plugins.cfg.dpkg-remove # /etc/OGRE/plugins.cfg - ogre plugins installed on Debian systems # [... same content as the previous one ...] -- Now, if I install 1.7.4-1, since it doesn't conflict with any other version of the library (I removed Breaks/Replaces, since it's an undesired feature, and if the files are not installed in the same path is not a problem), it cannot go wild and remove other binary package's config files. For one, the libogre-1.7.3 can continue to be installed when 1.7.4 is installed, 1.7.4 shouldn't remove it. And I don't know if because of this reason or because of the package name changed, when libogre-1.7.4 is removed but .3-3 (one of the versions still shipping /etc/OGRE/plugins.cfg) still installed, the file continues there. When I remove .3-3, the /etc/OGRE/plugins.cfg (unmodified) goes away. So I'm starting to get out of ideas about how to solve this. Ugh, things are getting complex. IMO we just have to worry about the following cases: libogremain-1.6.4 (from stable) - X (where X is whatever wheezy ends up shipping) libogremain-1.6.4 - libogre-1.7.3 version 1.6.3-5 (currently in testing) libogre-1.7.3 1.6.3-5 - X 1.7.3-6 (currently in unstable) - X Assuming that the severity of this bug is raised to serious to prevent 1.7.3-6 from transitioning into testing. If it transitions then we have to deal with: libogremain-1.6.4 - libogre-1.7.3 1.7.3-6 libogre-1.7.3 1.7.3-5 - libogre-1.7.3 1.7.3-6 libogre-1.7.3 1.7.3-6 - X Maybe that would be easier? I guess the question is what to do with the libogre-1.7.3 package that is about to go away with 1.7.4. While it'd be nice to maintain the co-installability of libogre-1.7.3 and libogre-1.7.4, without any reverse-dependencies I'd be happy for libogre-1.7.4 to conflict with libogre-1.7.3, and for it to steal the other package's conffiles and remove them when installed. Then, with no more conffiles to worry about, going forward libogre-1.7.4 can be co-installable with any later versions. -- Sam Morris s...@robots.org.uk -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#656997: libogre-1.7.3: Unmodified /etc/OGRE/plugins.cfg not removed on upgrade
Hi again, 2012/2/7 Sam Morris s...@robots.org.uk: Assuming that the severity of this bug is raised to serious to prevent 1.7.3-6 from transitioning into testing. If it transitions then we have to deal with: libogremain-1.6.4 - libogre-1.7.3 1.7.3-6 libogre-1.7.3 1.7.3-5 - libogre-1.7.3 1.7.3-6 libogre-1.7.3 1.7.3-6 - X Maybe that would be easier? I modified the package so 1.7.4 does conflict with the previous ones, so it continues to be the upgrade as before. I think that by forcing the new package to remove the config file of old packages it should be enough. E.g. when installing 1.7.4-1, if the previous package is installed, it happens the following: a) Pre-1.7.3-5, removes the file (unchanged since long ago, and in the last versions wrong anyway, because it didn't point to the multi-archified libs) b) 1.7.3-5 overwrites /etc/OGRE/plugins.cfg from previous versions with the one with multi-archified path, the file is removed c) 1.7.6, file in /etc/OGRE-1.7.3/plugins.cfg, gets removed. Since this version didn't remove /etc/OGRE/plugins.cfg and it doesn't contain itself the file, I think that it won't be removed. Only people installing this version will be affected (~3 days publicly available so far). Does this make sense and covers all cases, except the c) one? It's implemented in the current repository, can you please check this one? Should work with git-buildpackage directly. http://anonscm.debian.org/gitweb/?p=pkg-games/ogre.git;a=summary Another possible and more robust approach is to do the check by hand, and in the foreseeable future the new package will contain the equivalent of the current scripts but not skipping anything -- if *any* of the config file paths are there and match *any* of the known md5sums, they get removed. I guess the question is what to do with the libogre-1.7.3 package that is about to go away with 1.7.4. While it'd be nice to maintain the co-installability of libogre-1.7.3 and libogre-1.7.4, without any reverse-dependencies I'd be happy for libogre-1.7.4 to conflict with libogre-1.7.3, and for it to steal the other package's conffiles and remove them when installed. Then, with no more conffiles to worry about, going forward libogre-1.7.4 can be co-installable with any later versions. Yes, I think that I'm going to do this at the moment. Anyway, 1.8 should be available soon, in fact they already released -rc1 and should have been released by now. Many of the disruptive changes that I introduced were because I was thinking about preparing the upcoming (I believed upstream, and so I considered immient) 1.8 release, so most of these problems shouldn't have happened nor minor releases like 1.7.4 should have got in the middle... but well, here we are. My bad. Cheers. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#656997: libogre-1.7.3: Unmodified /etc/OGRE/plugins.cfg not removed on upgrade
reopen 656997 thanks I found that when I upgraded to 1.7.3-6 the conffiles were not removed: (Reading database ... 165610 files and directories currently installed.) Preparing to replace libogre-1.7.3 1.7.3-5sam1 (using libogre-1.7.3_1.7.3-6sam1_amd64.deb) ... Unpacking replacement libogre-1.7.3 ... dpkg: warning: unable to delete old directory '/etc/OGRE-1.7.3': Directory not empty Preparing to replace libogre-dev 1.7.3-5sam1 (using libogre-dev_1.7.3-6sam1_amd64.deb) ... Unpacking replacement libogre-dev ... Preparing to replace ogre-tools 1.7.3-5sam1 (using ogre-tools_1.7.3-6sam1_amd64.deb) ... Unpacking replacement ogre-tools ... Setting up libogre-1.7.3 (1.7.3-6sam1) ... Processing triggers for man-db ... Setting up libogre-dev (1.7.3-6sam1) ... Setting up ogre-tools (1.7.3-6sam1) ... Though it's not mentioned in the above messages, /etc/OGRE/plugins.cfg also still exists. I think this is because dpkg-maintscript-helper rm_conffile is only called in libogre-1.7.3.preinst; the man page says it should be called in the preinst, the postinst and the postrm scripts. This may be complicated by the local version number's I've added to the package in order to rebuild it against Boost 1.48. I'm not going to remove the files in /etc for now in case you want me to test the upgrade process. BTW, I noticed that debian/libogre-dev.README.Debian advises users to specify /etc/OGRE/plugins.cfg when they create their Ogre::Root instance. I think this file should be removed, or have its contents replaced with a warning that users should decide which plugins they use when they build their software, and ship their own plugins.cfg or just load their chosen plugins manually after creating their Root. Regards, -- Sam Morris s...@robots.org.uk -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#656997: libogre-1.7.3: Unmodified /etc/OGRE/plugins.cfg not removed on upgrade
Hi again Sam, 2012/2/6 Sam Morris s...@robots.org.uk: reopen 656997 thanks I found that when I upgraded to 1.7.3-6 the conffiles were not removed: [...] I think this is because dpkg-maintscript-helper rm_conffile is only called in libogre-1.7.3.preinst; the man page says it should be called in the preinst, the postinst and the postrm scripts. Thanks for reopening. I am creating a new version, with new upstream included, which hopefully it will be uploaded soon. I expect to fix the issue now, and also remove the /etc/OGRE-1.7.3/plugins.cfg for the version that it was shipped. Actually the problem are the many concurrent issues that I'm trying to fix at once, so I forgot about testing this properly before uploading, my bad. This may be complicated by the local version number's I've added to the package in order to rebuild it against Boost 1.48. I'm not going to remove the files in /etc for now in case you want me to test the upgrade process. Thanks for you help. BTW, I noticed that debian/libogre-dev.README.Debian advises users to specify /etc/OGRE/plugins.cfg when they create their Ogre::Root instance. I think this file should be removed, or have its contents replaced with a warning that users should decide which plugins they use when they build their software, and ship their own plugins.cfg or just load their chosen plugins manually after creating their Root. Yep, thanks for spotting that too. I thought about putting something in NEWS if I receive some indication/complaint from clients. Since at the moment there are virtually no packages depending on OGRE, maybe it's just not necessary. Cheers. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#656997: libogre-1.7.3: Unmodified /etc/OGRE/plugins.cfg not removed on upgrade
On Tue, 2012-02-07 at 00:02 +, Manuel A. Fernandez Montecelo wrote: Hi again Sam, 2012/2/6 Sam Morris s...@robots.org.uk: reopen 656997 thanks I found that when I upgraded to 1.7.3-6 the conffiles were not removed: [...] I think this is because dpkg-maintscript-helper rm_conffile is only called in libogre-1.7.3.preinst; the man page says it should be called in the preinst, the postinst and the postrm scripts. Thanks for reopening. I am creating a new version, with new upstream included, which hopefully it will be uploaded soon. I expect to fix the issue now, and also remove the /etc/OGRE-1.7.3/plugins.cfg for the version that it was shipped. ... This may be complicated by the local version number's I've added to the package in order to rebuild it against Boost 1.48. I'm not going to remove the files in /etc for now in case you want me to test the upgrade process. Thanks for you help. No problem. I looked into the conffile issue a bit further and I think that the dpkg-maintscript documentation needs to be changed. I filed http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=658854 where you can find a brief description of the issue; in summary, I think you should set the 'lastversion' to 1.7.3-7~ in the next revision of the package (assuming that the next revision will be 1.7.3-7 of course). The existing documentation would suggest you use 1.7.3-6, but this causes the conffile removal code to be skipped in the case of a user rebuilding the package with a local version number: the user would be upgrading from 1.7.3-6local1, which is greater than 1.7.3-6 and therefore rm_conffile thinks that it doesn't need to do anything. Any possible (sane) local version number is guaranteed to be 1.7.3-7~ however, and so that version number is safe to use when invoking rm_conffile. Regards, -- Sam Morris https://robots.org.uk/ 3412 EA18 1277 354B 991B C869 B219 7FDB 5EA0 1078 signature.asc Description: This is a digitally signed message part
Bug#656997: libogre-1.7.3: Unmodified /etc/OGRE/plugins.cfg not removed on upgrade
Package: libogre-1.7.3 Version: 1.7.3-5 Severity: normal /etc/OGRE/plugins.cfg was not removed when I upgraded to 1.7.3-5. Its md5sum matches the value stores in dpkg's database. You can use 'dpkg-maintscript-helper rm_conffile' in your maintainer scripts to remove the config file in a sane way (i.e., remove it unless it's been modified, in which case it's renamed). -- System Information: Debian Release: 6.0.3 APT prefers stable APT policy: (550, 'stable'), (540, 'stable-updates'), (520, 'testing'), (510, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.1.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libogre-1.7.3 depends on: ii libboost-thread1.46.1 1.46.1-8 portable C++ multi-threading hi libc6 2.13-24Embedded GNU C Library: Shared lib ii libfreeimage3 3.10.0-4 Support library for graphics image ii libfreetype6 2.4.2-2.1+squeeze3 FreeType 2 font engine, shared lib ii libgcc1 1:4.6.2-11 GCC support library ii libgl1-mesa-glx [libg 7.7.1-5A free implementation of the OpenG ii libglu1-mesa [libglu1 7.7.1-5The OpenGL utility library (GLU) ii libstdc++64.6.2-11 GNU Standard C++ Library v3 ii libx11-6 2:1.3.3-4 X11 client-side library ii libxaw7 2:1.0.7-1 X11 Athena Widget library ii libxrandr22:1.3.0-3 X11 RandR extension library ii libxt61:1.0.7-1 X11 toolkit intrinsics library ii libzzip-0-13 0.13.56-1+b1 library providing read access on Z ii multiarch-support 2.13-24Transitional package to ensure mul libogre-1.7.3 recommends no packages. libogre-1.7.3 suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#656997: libogre-1.7.3: Unmodified /etc/OGRE/plugins.cfg not removed on upgrade
Hi Sam, 2012/1/23 Sam Morris s...@robots.org.uk: Package: libogre-1.7.3 Version: 1.7.3-5 Severity: normal /etc/OGRE/plugins.cfg was not removed when I upgraded to 1.7.3-5. Its md5sum matches the value stores in dpkg's database. You can use 'dpkg-maintscript-helper rm_conffile' in your maintainer scripts to remove the config file in a sane way (i.e., remove it unless it's been modified, in which case it's renamed). Thanks for reporting and for the suggested fix. I will try to allocate time during the next days to fix it. Cheers. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
