On Thu, Jan 08, 2004 at 08:56:23AM +1000, Andrew Pollock wrote: > On Wed, Jan 07, 2004 at 06:18:28AM +0000, Andrew Suffield wrote: > > > > Treat it just like a fresh installation with a pre-existing printcap - > > whatever that means. The fact that the existing printcap was created > > with an old version of lprngtool is no more interesting in this case > > than if it were created by hand. > > > > I hope it doesn't do silly things in that scenario - that would be a > > more serious issue. > > An example is probably going to make the problem clearer: > > printcap entry generated with version 1.1.1: > <snip> > > Specifically, /usr/share/lprngtool/master-filter isn't provided by the newer > lprngtool, so that printcap entry is now busted-ass. Ah. Yes. That's not quite what I was expecting - it's not lprngtool that breaks when you upgrade, it's the printcaps that the old version generated. There's basically only one solution here - *don't* upgrade, at least not automatically. That means you change the package name, so people who were using the old version will continue using the old version. I'm not sure whether the old version should continue to provide the configuration interface (I'd guess that it should, but maybe you can do something that works better), but you definitely don't want to let it upgrade to a version that doesn't provide the filters - there's a big difference between breaking a configuration tool, and breaking printing entirely. It's not perfect, but it's the best we can do when upstreams don't provide an upgrade path (and it happens too damn often). -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- |
Attachment:
signature.asc
Description: Digital signature