Ken-- Thanks for your comments. Some counterpoints below. :) > While I like the consistancy, this sort of introduces a massive > documentation bug. People will read the Red Hat DS or 7.1 DS or latest > DS documentation, look for (say) setup-ds-admin.pl, and it will be > missing (renamed), and come right back to the mailing list asking for it > again. Most of the scripts I'll be working with won't be mentioned in the official Redhat documentation; they're peripherals, not central to the operation of the DS. (E.g., setup-ds-admin.pl -- which _has_ been renamed, incidentally -- is packaged in fedora-ds-base itself.) That said, it might be a reasonable compromise to create a package that installs a script, say, ds-schema-migrate, plus a symlink to that script from ol-schema-migrate.pl, but make the script generate a warning when it's called by the old name. This should make it possible to change the existing documentation -- mostly on the Fedora DS wiki, I believe -- referring to those scripts at our leisure, while not breaking old functionality. Thoughts? > I suspect the purpose of some scripts is to produce output. Heh, good point. I'll have to write that requirement a little more carefully. > Also, some scripts call other perl or shell scripts, and tying up > all those outputs neatly would probably involve rewriting them all. I'm still not deterred. If the programmer calls a command that generates unwanted output, it should be the job of the programmer -- not of the sysadmin -- to handle that output gracefully. > OK, but hey! Don't forget us Red Hat (paying) customers. I've had many a > cool new package refuse to run on Enterprise 4 because supporting > packages were "too old" or packages weren't available. I can understand > giving up on Enterprise 3, but right now E4 is still the massive user > base. I actually _am_ one of those paying customers, so I feel your pain. :) That said, Fedora DS is a Fedora project, and while it'd be nice to only allow RHEL dependencies, I don't think it's reasonable for a Fedora-related project to tie itself to that (slower) release cycle. In practice, this is really only a problem where a package requires a _newer_ version of something than is available for RHEL X.Y; I've rarely run into a package available for Fedora that isn't available, prebuilt, for RHEL, whether from Dag Wieers, EPEL, CentOS Extras, or any of the other third-party repos out there. I'll add some language stating that scripts _should_ endeavor to work on all currently supported RHEL releases, but I don't think we can make this a requirement. Thanks again! Great input! Chris St. Pierre Unix Systems Administrator Nebraska Wesleyan University
