Bug#84819: Rdesktop
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" |
Reply to: