The name would have change from release to release, since we are nowhere near to offer any kind of backward compatibility. We cannot offer source compatibility, let alone binary compatibility. If this proposal means we have to create by hand files called libppl<n>* for <n> = 5, 6, 7, ... one unrelated from the other as far as CVS is concerned, then I oppose this proposal. Even automatizing the creation of this files names libppl<n> from another source with a stable name seems _really_ overkill at this stage. Our 5 Debian users will have to uninstall the old PPL version when installing a new one. Keeping them both would be completely nonsensical today and even two years from now. The parallel with libc makes no sense: in a GNU/Linux system _everything_ depends on libc, so there this versioning thing is vital to make the system practically upgradable.
I propose we try to end up with something that works, to start with, omitting the version number from the package names. When we have something that works, then we will decide what to do... trying not to forget that the best is the enemy of the good.
Ok, that's just fine - I'll still try to find a solution - and if I find one, I will tell you... But - there is no need to uninstall the packages manually - if you just increase the version numbers, the debian-packaging system will take care of uninstalling older versions (of the same package). If you ever rename it to libppl<version-number>, you could add a "Replaces: libppl" - line to the control file.
So Matthew, what do we miss to make this Debian packaging system happy?
Well, my name is not Matthew - but I suggest
- debian/docs should probably contain BUGS README TODO and CREDITS - debian/rules is still missing
Regards, Michael