() Matthieu Moy <[EMAIL PROTECTED]> () Mon, 11 Aug 2008 12:04:56 +0200
What is "~/" here? The sysadmin's $HOME? The user's? Excellent question. The ~ stands for the user's home dir. If my sysadmin installs something on my machine, I don't expect to have to read a README file or edit my configuration file to let it work. Well, that's the next step on the janitor's journey: documentation. I think it's reasonable to look at a package's documentation before using it, especially if someone else installed it. If a package manager installs something on my machine, same goes for it. If you don't like to read documentation, that's your choice. However, if i were to maintain a package and you complained that it didn't work when your sysadmin installed it, i would direct you to read the documentation (also installed), and if the result was not satisfactory -- i.e., missing/unclear documentation -- take that as a signal to improve the documentation. I would put the effort of communicating the package's runtime idiosyncracies into the documentation, rather than into the configure script. The former helps the end user when the sysadmin is off and gone (or if the system later changes -- see below); the latter doesn't. > If that has to happen anyway, i don't see why it's necesarry to > burden the config/install process w/ checks for those programs. The _point_ of the configure script is to check as soon as possible that the program will have a chance of working. I understand your point (and used to hold that position myself, a while back), but disagree. > You could equally say that the default value doesn't assume > anything, because DVC never uses those values for "make" or "make > install". So, your vision of a sysadmin's work is to just run "make && make install"?? To me, the role of the sysadmin installing something is also to check that the program works (i.e. is correctly installed). Sometimes a sysadmin has too much to do besides "make all install". Sometimes a sysadmin doesn't know what is "correct" (for you). Sometimes a sysadmin doesn't know what is "correct" (for anyone). Sometimes a sysadmin doesn't know anything! (Or worse, doesn't care.) Sometimes a sysadmin knows all and DTRT, now, but the system changes. > the user will have to override it anyway. Why the hell would he have to? Give me just one case where a FreeBSD user would have to override the value given by the configure script of the package. Here are four cases: The dvc-site.el-chosen diff is buggy. The dvc-site.el-chosen diff points to a file that is no longer there. The dvc-site.el-chosen diff points to a file that is old (newer is better). The user requires a different diff per project. But what's the problem here? AAUI, your point is that asking the sysadmin to type --with-diff=something is too much work for him. My point is that runtime configurability is better left to runtime configuration mechanisms, and that those mechanisms should be both relatively standard and properly documented. With dvc-site.el, if the sysadmin just does a plain ./configure (no args), then the user can still un-break his installation by putting a correct value in his ~/.emacs. Without dvc-site.el, ... it just THE SAME. Except that you remove the way for the sysadmin to get it right at the first time. There, you said it. It is THE SAME. So, why have it, given the possiblity of those four cases above (and others)? Perhaps you have better experience w/ (good) sysadmins than i have, but IMNSHO, involving the sysadmin (even the good ones) in matters of runtime configuration adds needless complexity. I don't have FreeBSD installed, so I can't easily test what DVC gives with a FreeBSD non-GNU diff command. If DVC just works with it, I agree with you, and the FreeBSD package should just keep diff as the default. But since the maintainer actually had to patch the program, I suspect he had a good reason. I don't doubt there was a good reason. I'm just suggesting the resolution of runtime configuration issues not have seeds in the configure script. A compromise (and more idiomatic) approach would be to mention in the documentation (which configure could noisily hint at, upon completion) that the sysadmin can create/edit site-start.el to add the (setq ...) forms, in the same manner that users would, in their personal customization file. See: (info "(elisp) Init File"). thi _______________________________________________ Dvc-dev mailing list [email protected] https://mail.gna.org/listinfo/dvc-dev
