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 -- Fedora-directory-users mailing list Fedora-directory-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-directory-users
