%% Wayne Topa <[EMAIL PROTECTED]> writes: >> I already know how to do this; what I want to know is whether there is >> any way to do it in Debian, so that when I upgrade my Debian packages >> console-tools (or kbd, I don't care much which one) my customizations >> are kept automatically without my having to go back in and fix them up.
wt> I made a custom.map file, for slackware, from that article 5-6 years wt> ago. I have used it, without modification, on Debian since bo. I am wt> currently using it on potato, slink and woody boxes. I have never wt> had to change it. There must be some reason why upgrading these packages keeps installing new versions of the keymap files. >> Look, for example, at how the X fonts are done: there is a directory >> /etc/X11/fonts/<dir> for each font type, and in there you can add your >> own files. For example, you could add a file >> /etc/X11/fonts/100dpi/my-fonts.alias and put your own font aliases in >> it; the system will automatically include and install those aliases for >> you when you run update-fonts-alias. This way, you don't have to edit >> a system config file to add your own aliases, which would entail >> re-editing those config files (or merging them or whatever) every time >> you updated to a new Debian X fonts package. wt> My custom.map file is only for the console. I setup keys for X in my wt> .xmodmap file. Well, of course. Your comment is a non sequitur. I'm talking about X fonts above solely as an illustration of a good method of handling user customizations. Since you bring it up, though, I'll point out that modmap is another example of good separation between system files and user customizations: you can write your own .xmodmap file as a separate file containing _only_ the changes to the standard key bindings. This is what I want to do with the console key map: have my own file with _only_ the changes, not the entire keymap. wt> Maybe RedHat has a tool for that. They seem to be pretty good at wt> making tools for helping new users. I don't use redhat as I wt> prefer to understand what I am doing. Another non sequitur. What tools Red Hat may or may not have is not helpful to me since I use Debian. >> I was hoping there was some similar way to defined my own "console key >> map customizations file" as a separate file, and have the console-tools >> (or kbd) automatically install/append/whatever that file into its >> default keymap when it's created. wt> Well I must not be understanding you correctly then. I made my wt> "console key map customizations file" myself and don't know or wt> want any file so general that it would modify my custom key maps. ?? I don't want anything to modify my custom key maps, of course--that's what it does now and what I'm trying to avoid. I want a way to customize the standard key map, without completely replacing it. This latter is what you seem to have done: if I'm understanding you correctly you don't have a "console key map customizations file", you have a "customized console key map file". The distinction is very important. Again, X modmap is a good example: you don't put the entire X keymap in your .xmodmap file, you only put the _changes_ there. That's what I want for the console: a file containing my changes, which is automatically loaded and overrides settings in the standard key map, rather than keeping an copy of the entire keymap myself with my changes embedded in it. This can be done at the time the keymap file is created, of course, unlike X modmap which is done dynamically. It has nothing to do with "knowing the system" or any other such stuff: I've been using Linux since 1993 (I used dd on my SPARC SunOS 4.1 workstation to create my first Linux boot floppy :) and UNIX a lot longer than that--I'm not _incapable_ of making these changes myself. Now that I'm an old fogy I just don't have time to fool with it; there are much more important things I want to do. That's why I moved to Debian from Slackware: I just don't have any urge to build everything myself anymore. I've done that for many years (and this was back before autoconf, when building Emacs and GCC and stuff was actually an adventure :)), I know how to do it, and it doesn't interest me any longer. I build locally and hack the packages I'm actively involved in, and let other people worry about the rest. But, I am willing to spend some time explaining what I want in the hopes that it will save me, and/or someone else, time in the future. -- ------------------------------------------------------------------------------- Paul D. Smith <[EMAIL PROTECTED]> HASMAT--HA Software Methods & Tools "Please remain calm...I may be mad, but I am a professional." --Mad Scientist ------------------------------------------------------------------------------- These are my opinions---Nortel Networks takes no responsibility for them.