On Sat, Oct 14, 2006, Peter Samuelson wrote: > So, I've done that, but now I have second thoughts. libsvn-javahl is > not in sarge, so this is only to support upgrading from old etch to new > etch. Or from ubuntu dapper to etch. Is it really necessary to > support that?
You have a point that it's not necessary for the pure stable to pure next stable upgrade path. You also listed other upgrade paths which are worth supporting, there is one more to consider as well: backports. In my case, I installed libsvn-javahl because of Subclipse (Subversion support in Eclipse, but not in Debian yet), and I suppose a lot of people do so. I did so on a Debian sarge, an Ubuntu dapper, and a Debian sid, and noticed the upgrade problem on my sid too. > I'd still like a second opinion on a libsvn-core-perl dummy package. > That one actually _is_ in sarge. I don't think it will actually bite > users - I think it's mainly used by other debian packages such as > git-svn and svk, which already depend on the new package name - but I'm > not really sure. I agree that if it's only pulled by dependencies, you don't need a dummy package, only the dependencies need to be updated. In the case of libsvn-javahl / libsvn-java, there are no rdeps, hence people are more likely to have trouble upgrading their systems since they are not relying on dependencies. This is certainly not a common scenario for which we usually have dummy packages. -- Loïc Minier <[EMAIL PROTECTED]>
