NK> Jake Colman <jake.colman(a)xemacs.org&gt; writes: NK> I don't know whether there are historical reasons to keep them NK> separate. Some parts of misc-games are not really games in a strict NK> sense. IMO it would not harm to put the three packages together. NK> Although, I would opt for 'games' as name. Assuming noone objects how would we handle this? CVS does not easily handle movement of files. Should we just copy the files from the old directory to the new, 'cvs remove' them from the old, and 'cvs add' them to the new? Of course I'd have to update the appropriate files in the target directory to let them know about the new .el files and I'd probably create at least a skeleton .texi file for the whole shebang. -- Jake Colman -- XEmacs Tinkerer

NK> If nobody objects, I can move the sources in the repository and remove NK> the other cruft. Thus, we still have the files' histories around. Ok. Let me know when you want to actually do this. We'll coordinate so that after you have moved the files around in the repository and gathered them into games I'll commit the Makefile and package-info.in changes. I would also add a .texi too. We'll wait for approval and then I'll let you know when I'm be ready to commit. Then you move the stuff around and away we go! NK> That would be great. Still, I'd like to hear from others what they NK> think of it, in particular from the maintainers of the several NK> single-file packages. Want to take bets on whether any of them chime in? :-) -- Jake Colman -- XEmacs Tinkerer

Adrian Aichner <adrian(a)xemacs.org&gt; writes: Nope, you should see it all. norbert.

Ville Skyttä <scop(a)xemacs.org&gt; writes: [...] Thanks for the input. Or rewrite it? Dunno... norbert.

SJT> Ville is right: don't delete the old dirs. Just cvs rm. So if we want to do it that way, I don't need any special support from Norbert. I can just cp the files to the new directory, 'cvs remove' them from the old dir, and 'cvs add' them to the new dir. Agreed? But what about PUI? Won't it still, as Ville said, list the old package directories? BTW even if you like the idea of more granularity do we really need to list all the games libraries seperately? I think one package is really the better way to go, at least for games. -- Jake Colman -- XEmacs Tinkerer

SJT> Ville is right: don't delete the old dirs. Just cvs rm. Jake> So if we want to do it that way, I don't need any special Jake> support from Norbert. I can just cp the files to the new Jake> directory, 'cvs remove' them from the old dir, and 'cvs add' Jake> them to the new dir. Agreed? Not quite. The point is that if the cp is done in the CVS repository, the new files will (a) automatically appear when you do cvs update -d and (b) preserve the old history (redundantly). And (c) somebody has to redirect the module aliases at the new repo dirs. Jake> But what about PUI? Won't it still, as Ville said, list the Jake> old package directories? Yes. We need to figure out how to handle that before Norbert releases new packages. Jake> BTW even if you like the idea of more granularity do we Jake> really need to list all the games libraries seperately? I Jake> think one package is really the better way to go, at least Jake> for games. I'm agnostic on that. Pre-PUI changes it seems reasonable, as long as we have a strategy for going in the opposite direction if it becomes feasible to have a "games" package that has no content of its own, but pulls in "mine" and "tetris" and "doctor". Real package dependencies should go a long way to handle this. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.