On Mon, Apr 11, 2005 at 05:04:36PM +0200, Alexander Schmehl wrote: > I know, we are quite late with this, I know that the "last call for > uploads" has been send a couple of days ago and I know, that the auto > builders are quite busy these days. > That's why I'm quite unsure what to do in this situation. > As you might know, the game tuxracer is dead by upstream, although it > works well, and we could guess that we don't need to touch it again, > when sarge is released (speaking of security updates or such things). > Therefore, there is no real need to touch this package, especially since > it is still fun to play and well known to many people. > But there is ppracer (which I maintain), which is based on tuxracers > code and has an active upstream (which BTW is using Debian, too). The > tuxracer Maintainer - Oliver M. Bolzer <oliver@debian.org> - and I > agree, that ppracer should replace tuxracer sooner or later (see > Bug#281596). > The open question is: Should we try this transistation right now? > Before Sarge is released? > I'm not sure about that. On the one hand tuxracer still works while > ppracer has not even entered testing, on the other hand I'm wondering if > it serves our users well to still give them old, unmaintained code. > The "plan" for this small transistation would be the following: > - upload a new ppracer which has: > - Replace: tuxracer (< 0.61-6.4) > - Conflicts: tuxracer (< 0.61-6.4) > - Provides: tuxracer > (- has a slighlty changed manpage and icon) > - Leave the rest of the package as it is Why is this needed? I don't see much benefit to these changes; there is certainly no need, on the filesystem level, for the use of Conflicts: here. Given that you also plan to upload a transition tuxracer package, I don't think the Replaces: and Provides: matter either. This is not a case of coexisting alternative packages, since tuxracer will become a dummy package. It would certainly be a more economical use of our buildd resources to not re-upload ppracer for this change. > - upload an empty tuxracer dummy package (included in ppracer) > - Depends: ppracer > - Long description contains the usual "dummy package, can be removed, > use ppracer instead" If we don't need the ppracer upload, then uploading a separate tuxracer dummy package would be easy to do and would not add to the load on the buildd network, so I would have no objections to that. > - upload a new tuxracer-extras package (this is maintained by me, just > some extra courses) > The only tricky thing that I see is, that the new tuxracer-extras should > either not hit sarge before the new ppracer or it should just be renamed > to ppracer-extras (no problem, tuxracer-extras has not been in a stable > release, so no transistation package is needed). Yes, it seems like that package should just be renamed. Cheers, -- Steve Langasek postmodern programmer
Attachment:
signature.asc
Description: Digital signature