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
