I've also been keeping a package for my personal use. Just screwed up updating it to the latest unified patch (19-6-3) though. Whoops.
I'm thinking that a version-patchlevel type scheme should do the trick. ie: 1.0.0 is the source as is, 1.0.0.19.6.3 is the original source + the latest patch 1.1.0 - the next release. This scheme will work nicely as long as you keep version numbers out of the package name. (apt-get install rdesktop, not apt-get install rdesktop1.0) Many maintainers have recently made the mistake of using prerelease versions with the final version followed by a datestamp. (2.3.0-20010325). This leads to things like 2.3.0-final to get the versioning back on track. A version like 2.2.9.20010325 should have been used, then when 2.3.0 is release apt would have noticed that 2.3.0 > 2.2.9.20010325 and gotten the new version. Going by this, 1.0.0 would tranition to 1.0.0.patchlevel, and 1.0.0.patchlevel would transition to the next patchlevel or 1.1.0 cleanly. The downside to this is that each new patch would be considered a new upstream version, and since it's in patch form not tarball form many of the automated build tools won't work as advertised, so you'll have to do a little extra work. Also remember that each time you use dch -i you will create a new incremental package that will replace the package your previously created, so that is another option for handeling new patchlevels that may be simpler and shorter. Just make sure you make note of it in your changelog. Packaging with the different patches presents a new chalenge. I haven't figured out how to apply a new patch without going back to the original 1.0.0 source. Then there's the issue of the dangling non-free lib included in the original rdesktop source. After patching this isn't an issue, but Debian will still be distributing the original source that includes the non-free lib until 1.1 is released. This is a question for debian-mentors (or maybe even debian-devel), as modifying the original source tarball to remove this lib would cause rdesktop to not to compile, and most likely a policy violation. Perhaps Matt will consider resolving this issue before others, thus creating a 1.0.1 that debian can distribute. Doing so might give the unified-patch folks a little work. If Matt Chapman has a tentive date for the 1.1.0 release, and that date is before the Woody freeze date, apply for maintainer/developer status now. Last time I checked you still have to become a maintainer/developer, and that process does take time. (Finding a sponser, face to face keysigning, etc.) Once you're a maintainer, getting the 1.1 release into Woody shouldn't take long, and as long as it's bug free, should survive the freeze. I think what I would do is: Become a developer/maintainer. On your people.debian.org homepage, put up a page describing the current problems with the package (explain why 1.0 will never be an official package.) On people.debian.org, maintain an apt-getable repository for your rdesktop package so far so that people who would find it useful in it's current state don't have to duplicate your efforts, and interested parties can submit packagine (let me repeat that, PACKAGING!) bugs to you. You don't want to deal with any bugs that ARE NOT related to PACKAGING until your package is in unstable. Hope all that was helpful on some level. ;) | Andrew S. Zbikowski | Home: 763.591.0977 | | http://www.ringworld.org | Work: 763.428.9119 | | http://www.itouthouse.com | PCS: 612.306.6055 | | His power apparently lies in his ability to | | choose incompetent enemies. | | - Crow T. Robot, MST3K, "Prince of Space" |
