[Fedora-directory-users] Request For Comment: fedora-ds-utils project

[Chris St. Pierre]

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