Bug#656997: libogre-1.7.3: Unmodified /etc/OGRE/plugins.cfg not removed on upgrade

2012-02-17 Thread Sam Morris
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-02-17 Thread Manuel A. Fernandez Montecelo
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

2012-02-17 Thread Sam Morris
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-02-17 Thread Manuel A. Fernandez Montecelo
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-02-16 Thread Manuel A. Fernandez Montecelo
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-02-07 Thread Manuel A. Fernandez Montecelo
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

2012-02-07 Thread Sam Morris
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-02-07 Thread Manuel A. Fernandez Montecelo
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

2012-02-07 Thread Sam Morris
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

2012-02-07 Thread Manuel A. Fernandez Montecelo
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

2012-02-06 Thread Sam Morris
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

2012-02-06 Thread Manuel A. Fernandez Montecelo
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

2012-02-06 Thread Sam Morris
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

2012-01-23 Thread Sam Morris
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

2012-01-23 Thread Manuel A. Fernandez Montecelo
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