also sprach Gergely Nagy <algernon@bonehunter.rulez.org> [2004.12.21.1130 +0100]: > CVS doesn't like symlinks. So if I have ~/etc/yada.conf, and ~/.yadarc > is a symlink to that, CVS will probably think they are two different > files. which is why you keep ~/etc in CVS and maintain the symlinks manually (I have a symlinks.d in each directory with files in it describing the symlinks, and a cronjob that takes care of enacting them. > About using it on systems that do not approve of the migration: > one has to symlink files back, which gets you a cluttered $HOME > AND an ~/etc. Worst of both worlds, thankyouverymuch. Works very well and allows you to simply filter all links from ~. > > I do not consider that an argument against my proposal, rather > > an argument for your system administrators to upgrade hardware > > and policy. > > Not an option. The system has been in used for as far back as > I can remember and it works flawlessly, apart from this little > annoyance I can handle fine right now. There's no reason to > upgrade neither hardware, nor software. Not to mention that would > cost more than the owners are willing to spend, for no financial > gain. The point is more that I see no reason why one should honour reluctance to accomodate new requirements as an argument against potential innovation. We do not cap other cars at 60 km/h just because your ancient Bentley does not do more (albeit being beautiful and flawless). > > We are not kicking KDE 3 out of Debian because I still have some > > systems with 200 Mb harddrives. > > Nor do we have to install it at all, while dotfile migration wouldn't be > a choice, were your proposal accepted. Installing KDE or not, is a > choice. Fair enough, bad comparison. Anyway, to do dotfile migration, we need to simply get a critical mass of upstreams to change. Then we need no symlinks and eventually it will all take its natural course. If by the end there are only few offenders, we can then use symlinks while beating them over the head with cluesticks. > Furthermore, as others noted in the thread, FHS is, or should, be > able to document existing practice - or when there are multiple > alternative implementations, choose one and document that. It > should not intrude into areas it has no business with. I never said it should. Read carefully! > > Catch 22. It's never going to happen unless we do it. > > Yes. It won't, unless you can persuade a large number of > developers that what they've been doing wrt dotfiles in the past > few years was a bad idea to begin with. I do not see any chance of > success, to be honest. Your glass is half empty when it could be half full. It's not that they have been doing anything wrong, but they may be able to do it better. > - Symlink the config file automatically: this would either move the > configfile to the new location and symlink it back to the old one, or > the other way around. > Pros: Easy migration if nothing breaks and does not break $HOME-in-CVS > if done right. > Cons: Clutters $HOME even more than it was before, since the old file > must remain in place for $HOME-in-CVS to remain working reliably. And > many users will not notice the migration, will end up with a more > cluttered home, and the purpose is defeated. This is out too.. The more cluttered $HOME now contains precisely one additional entry. > At the moment, I can't think of any more solutions. You have listed them all, pretty much. I also appreciated your post, which is well argued. I shall now retreat to my cave and only come out again when hell freezes over, or when I found sensible answers, whichever one happens first. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft <madduck@debian.org> : :' : proud Debian developer, admin, user, and author `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!
Attachment:
signature.asc
Description: Digital signature