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

Reply via email to