Re: [Fedora-directory-users] Request For Comment: fedora-ds-utils project
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