() Matthieu Moy <[email protected]> () Mon, 11 Aug 2008 21:43:39 +0200
I accept reading the documentation to learn _how to user_ a program. But documentation shouldn't be needed to _allow the program to work_. Honnestly, did you read the Firefox manual before launching it? What does a web browser (extremely limited operational model) have to do w/ a generalized development tool (complex (but yet simplified :-) operational model)? Actually, when i first installed Firefox, it was before Debian picked it up and i did indeed read around the net a bit (using w3m) for customization tips like how to disable the scroll bar. Well, clearly, we don't have the same notion of what a good sysadmin is. But what you don't understand is the difference between _asking_ the sysadmin to do something, and _requiring_ him to do so. Actually, i understand this very well. > 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. It is not in the FreeBSD package. > The dvc-site.el-chosen diff points to a file that is no longer > there. It does not in the FreeBSD package. That is good news for the FreeBSD package and its users. > The dvc-site.el-chosen diff points to a file that is old (newer is > better). Then you have to give me a senario where someone would use the package manager to manage DVC, and would install diff by hand somewhere else. I can't find any. You have to use your imagination a little. I can't help you w/ that. > The user requires a different diff per project. Really? Why would he do so? (and how would you do that anyway?) Some diff programs support selective ignorance (e.g., GNU diff with `-I RE'). If there are vcs "tags" (e.g., "$Id$" of RCS of yore) in the source code, a common method is to write a simple project specific diff wrapper script: #!/bin/sh exec /usr/bin/diff -I '^;;;.*$Id' "$@" named, say "diff-ignoring-RCS-Id", and then use that in all places diff would be used (for that project). Now, none of your senarios are credible in the cases of the FreeBSD package, and you still claimed that "the user will have to override it _anyway_.". I'm sorry that these situations do not seem credible to you. I can't help you w/ that. > There, you said it. It is THE SAME. So, why have it, Because it's an additionnal feature that takes around 20 lines of code in DVC and that solves 99% of the problems. Simple solution to simple problems. > 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"). And what simple solution do you have for the FreeBSD package? (actually, it seems the package wasn't ported to DVC, but the Xtla port is still there) (up to now, I didn't see a senario where dvc-site.el would be harmfull, just cases where it's not useful) When i say harmful, i mean it from a maintenance perspective (which is the primary pov of a janitor). What DVC promises/provides for the user must be maintained. I can tell you that if DVC makes it into Emacs, dvc-site.el will most likely be removed pretty quickly, precisely to ease maintenance. My hope is that we can find a way to pre-emptively eliminate it, in the process putting ourselves in the Emacs maintainers' shoes, thus easing DVC acceptance and reducing the number of adaptations that would be required in the event (smoother transition). All my effort in the role of the janitor is to such ends, in fact. thi _______________________________________________ Dvc-dev mailing list [email protected] https://mail.gna.org/listinfo/dvc-dev
